Наш мир устроен очень странно. И чем дальше, тем становится страннее. И хрен поймешь, в чем дело.
Вот есть на свете инженеры и программисты. Иногда в одном лице. Люди, понимающие, что такое алгоритм. Более того – люди, создающие эти алгоритмы. Прекрасно знающие, что созданный алгоритм подходит для решения одной задачи, но не годится для другой. Понимающие, что если алгоритм чуть изменить, то он сможет решать смежные задачи. Не стесняющиеся выкинуть половину чужого алгоритма, чтобы он лучше решал текущую задачу.
Программисты создают решение под задачу, или под класс задач. В этом суть профессии. Там, где это возможно, используют готовые куски своего или чужого кода. И всё у всех хорошо.
Но, как только дело доходит до создания алгоритмов за пределами компьютера, программисты вдруг теряют голову. Я не говорю о рисовании схем алгоритмов на бумаге, как это было на экзамене в универе – тут любой из нас справится.
Я говорю о «внедрении методик», «работе по фреймворку», «обязательном использовании всех артефактов». О сектах, короче.
Немного идиотизма
Все знают, что такое условный оператор. Без него нет никакой жизни. Ни один приличный алгоритм работать не будет. Ни в компьютере, ни в жизни.
А теперь представьте: появился некий человек, допустим – Джон, и заметил, что в бейсике есть условный оператор. Поковырялся, разобрался, убедился – есть, работает, без него никак.
Допустим, Джон – туповат. Но решил покорить мир. Пошел продавать Бейсик. Не сам язык, а некую «крутейшую методику разработки программного обеспечения», центральным звеном которой является… А не скажет Джон, пока курс не пройдете.
Ладно, нашлись любители курсов, тем более, что цена не высока. Пришли, послушали, ахнули. Главным элементом крутейшей методики разработки программного обеспечения является Условный Оператор. Много послушали про условный оператор. Например, о том, как превратить его в оператор множественного выбора. Еще раз ахнули – какой могучий Условный Оператор.
Половину аудитории составляли программисты. Поржали, ушли домой. Еще четверть составляли менеджеры. Призадумались, позадавали вопросы, кто-то решил внедрить эту крутейшую методику у себя. Последнюю четверть составляли такие же, как Джон. Они уговорили парня на создание франшизы, Сообщества, Центра Сертификации и Университета Условного Оператора.
Программисты с курса вернулись на работу, уже не помня об Условном Операторе. Но через час пришли менеджеры и объявили, что теперь разработка ПО будет вестись по крутейшей методике. Да, которая про Условный Оператор. И вообще, писать лучше на бейсике.
Робкие, а то и не робкие возражения программистов были проигнорированы. Фразы типа «блин, это условный оператор, он везде есть» были восприняты как попытки повыпендриваться. Колесо закрутилось.
А Джон быстро понял, что мало одного Условного Оператора. Еще должен быть Цикл, Подпрограмма, Переменная, Массив и т.д. Надо бы как-то все это назвать… Одним словом… О, пусть это будут Артефакты! Ни больше, ни меньше!
Осталось главное: внести в методику пункт о том, что крутейшая методика разработки программного обеспечения – это целостное, холистическое знание. Значит, из него нельзя выкинуть ни одного куска. И в него нельзя ничего добавлять – работать перестанет. Как написано, так и делай.
Благодаря энтузиазму Джона и его друзей теперь весь мир пользуется не условным оператором, а Условным Оператором, не циклом, а Циклом, и т.д., по списку. Те, кто понимал идиотизм ситуации, давно ушли на пенсию или заткнулись. Те, кто пришел недавно, свято верят, что Условный Оператор – это часть крутейшей методики разработки программного обеспечения, созданной Джоном. А все остальные условные операторы – жалкое подобие, блеклая копия и выдранный из контекста кусок Знания.
Любой, кто посмеет подать голос в интернете (или, не дай-то Бог, внутри команды), будет подвергнут яростному осуждению и гневному минусованию – ишь ты, валенок, не видишь преимуществ Условного Оператора! А если несчастный попросит объяснить, в чем смысл и отличие от условного оператора в C++, javascript или даже 1С, получит в ответ «это невозможно объяснить», «тебе не понять», или «иди читай гайд».
Инструменты и алгоритмы
Все понимают, что такое условный оператор, и как его использовать в алгоритмах. Точно так же все понимают, что такое, например, стикер с записанной задачей. Стикеры появились до скрама, и живут вне его. Посмотрите на компьютер бухгалтера, снабженца или продавца. Они еще не изжили привычку вешать на монитор кучу стикеров со срочными задачами. На одном из стикеров будет написан пароль.
Любая методика легко разбирается на инструменты, принципы и связи. Так же, как любой алгоритм разбирается на фигурки разных форм и назначения – начало и конец алгоритма, действие, условие, подпрограмма.
Любая методика имеет область применения. Не всё там абсолютно – есть более подходящая среда, есть – менее. Так же, как и у алгоритмов.
В любую методику можно вносить изменения. Выкидывать куски, добавлять новые, модифицировать конкретные инструменты. Так же, как и алгоритмы.
Любые методики можно миксовать, целиком или по кускам. Взять половину от одной, четверть от другой, еще четверть – выдумать самостоятельно. Когда вы создаете приложение или сервис, для вас это очевидно.
Правда, остается вопрос – будет ли методика методикой, если ее поменять?
Вот как отвечает на этот вопрос, например, широко известный Scrum Guide:
«Роли, артефакты, правила и события Скрама не подлежат изменению. Хотя использование отдельных элементов данного фреймворка допустимо, но полученный результат не может называться Скрамом. Скрам существует только в качестве цельного фреймворка, но он может вмещать в себя другие техники, методологии и практики.»
Немного напоминает Джона и его Условный Оператор, не правда ли? Вроде как, меняйте, если хотите, только это будет не скрам. И каков будет результат – хрен его знает. На всякий случай отметили, что внутрь можно попробовать чего-то засунуть. Но костяк должен оставаться. Иначе… Даже страшно представить.
Так ли уж страшно? Что будет, если часть артефактов выкинуть или заменить? И вообще, какой в них смысл? Откуда они взялись? Почему считается, что они работают только в таком сочетании, как решили авторы?
Попробуем разобраться по частям.
Спринт и Бэклог Спринта
Отличный инструмент, кстати. Изобретен, наверное, лет тысячу назад. Только назывался всегда по-разному, но самое, наверное, распространенное – «План». А по-человечески – «сделать определенный объем работы за определенный промежуток времени».
Мне, как 1Снику, он больше известен, как объемно-календарное планирование (ОКП). Широко применяется при планировании производства и продаж. Например, план продаж менеджера, равный 1 млн. рублей в месяц – это бэклог и спринт. Иногда достаточно цифры, иногда бывает разбивка по группам продукции, или ограничения по рынку сбыта, или даже есть конкретный перечень номенклатуры, если того требует стратегия компании.
В производстве еще проще. Втулок – 1000 шт, валов – 2000 шт, роторов – 500 шт. Это, допустим, недельный план. Он же – бэклог недельного спринта производственного участка. Правда, рабочим можно не объяснять, что это – не план, а спринт.
Инструмент хорош в сравнении с распространенным управлением по срокам, когда пул задач программистов оценивается по трудозатратам, упорядочивается по какому-либо критерию, и у каждой задачи рождается срок выполнения. В производстве это называется посменным, или цеховым планированием, из которого потом создаются задания на производство, содержащие перечень деталей и полуфабрикатов, тех.операций, материалов, входов и выходов (где что взять и куда передать результат).
Для программистов цеховое планирование работает плохо, тут и обсуждать нечего. Время обработки детали на конкретной модели станка известно давно и достаточно точно. Периодичность обслуживания – тоже. Достаточность материалов оценена. Бери и делай. Вариации, мешающие выполнению плана, в серийном производстве обычно не оказывают значительного влияния. А если оказывают – есть прекрасные методы для их анализа и устранения.
Вариации программиста намного сильнее. Он ведь – не станок, как бы того не хотелось некоторым менеджерам, пришедшим в ИТ из продаж или производства. Поэтому цеховое планирование (задача + срок) для программиста не годятся. Вот и придумали толковые люди – надо подняться на уровень выше, не расписывать исполнение по минутам, а дать объем на период. Только название другое придумали – спринт и бэклог.
Наполнение объемно-календарного плана производства строится по принципам, схожим с формированием бэклога спринта. Даже есть такое понятие – «набрать план». Есть потребности того же отдела продаж (= большой бэклог), есть пропускная способность производства (= возможности команды в цифрах), плюс есть понятные критерии выбора – сумма продаж, рентабельность каждой позиции, параметры заказчика (например, условия оплаты). Набрал план производства – и сразу видишь, какой примерный финансовый результат получишь. Это не эфемерный «релиз».
Есть ли недостатки у этого инструмента? Разумеется, как и у любого другого.
Если разобраться, бэклог спринта – то же цеховое планирование, только без выстроенной последовательности решения задач. Поэтому у всех задач один срок выполнения – конец спринта. Раз срок у задач один, то появляется неприятный эффект – в начале спринта активность может быть значительно ниже, чем в его конце.
Так работает любая человеческая психология. Всегда хочется поваландаться в начале периода исполнения, будь то одна задача, или бэклог. Отдохнуть от прошлого периода, особенно – от его финальной части, когда пришлось выдать «на гора» колоссальный результат. Есть, конечно, люди стабильные и ритмичные, работающие всю неделю на одной скорости, но большинство начинает «нормально работать» где-то в среду.
Можно ли обойтись без спринта и его бэклога? Легко.
Например, применив инструмент «как можно быстрее». Вообще, это не прапорская замашка, а вполне себе нормальная стратегия того же цехового планирования (As Soon As Possible, ASAP). Означает, что выпуски будут «прилипать» к началу отрезка времени, т.е. к понедельнику, а не к пятнице, как при стратегии планирования «точно к сроку» (As Last As Possible, ALAP).
Планирование, как таковое, в этом случае не нужно. Есть бэклог продукта, есть приоритеты, есть правило «как можно быстрее». Берешь первую и делаешь. Закончил – берешь вторую. И так – от забора до обеда. Спринт, а точнее – его сущность, т.е. отрезок времени, можно оставить для понимания и анализа производительности (неделя к неделе, месяц к месяцу, и т.д.).
Есть ли недостатки у стратегии «как можно быстрее»? Конечно, миллион. Во-первых, человек может быстро устать. Во-вторых, он будет чувствовать себя станком. В-третьих, он, скорее всего, сбежит – туда, где используются обычные спринты с бэклогом. Или просто ставят задачи и ждут результата. В общем, где поспокойнее. Но практика показывает, что и «как можно быстрее» вполне можно жить годами, если здраво понимать, что это стратегия планирования, а не потогонка.
Можно ли выкинуть спринт и его бэклог? Нет. Не потому, что это – уникальные придумки того же скрама, а потому, что это естественный способ планирования, которым, в той или иной форме, пользуются все. Вариаций много, принцип один – нужно сделать определенный объем работы за определенный промежуток времени.
Является ли такой инструмент, как спринт, уникальным и ключевым элементом какой-либо методики? Нет. Это всё равно, что утверждать, будто набор кода на клавиатуре – уникальная придумка какой-то методики. Почти все тексты набираются на клавиатуре.
Скрам-доска
Формально, доска не является артефактом или правилом, но, думаю, про нее тоже стоит поговорить, потому что есть среди людей довольно явный паттерн: скрам – это доска со стикерами.
Тут, в общем-то, вы сами всё понимаете. Доска со стикерами, на которых записаны задачи, не является чем-то уникальным. Это, грубо говоря, кроссплатформенный инструмент. У меня жена на холодильник иногда стикеры лепит со списками дел, хотя ничего не знает ни про какой скрам.
Хорош ли этот инструмент? Смотря с чем сравнивать. Да, пожалуй, хорош.
Например, он позволяет быстро оценить, окинуть взглядом пул задач. В компьютере, или любом другом электронном устройстве, задачи нужно листать – в один экран всё, обычно, не помещается. Следовательно, в один взгляд – тоже.
Еще важный плюс – общая доступность для команды. В любой момент можно подойти и посмотреть, не надо заходить в какую-то систему, искать, делать выборку и т.д.
Многим нравится невиртуальность доски. В компьютере ведь все – виртуальное, руками не потрогаешь. А тут – пожалуйста, хоть облизывай. Некоторые, в этой связи, любят пробковые доски. Разница – примерно как между бумажными и электронными книгами.
Конкретно для скрам-доски можно отметить такое преимущество, как разделенность на две части – в работе и выполнено. Бытовое обращение со стикерами предполагает выкидывание тех, что уже завершены – не очень хорошо, т.к. прогресс виден хуже.
Есть ли недостатки у скрам-доски? Конечно. Как и у любой доски.
Начать с бытовых – сквозняки, некачественные стикеры, плохой почерк, саботаж. В результате – потерянные задачи и неразбериха в управлении.
По доске не очень виден прогресс. В целом за спринт – да. За сегодня, вчера – нет. Отсюда необходимость в ежедневных обсуждениях.
Конкретно по скрам-доске не видны статусы задач, если жизнь сложнее, чем «запланировано» — «сделано». Предпочтительнее выглядит канбан-доска.
Доска не позволяет нормально работать, если команда территориально распределена. Поэтому появляются электронные доски.
Электронная доска, как мне кажется, верный признак сектанства. Она потеряла все преимущества обычной, но, по какой-то неведомой причине, ей продолжают пользоваться. Вероятно, просто потому, что это – доска. Часть Методики.
В общем, инструмент, как инструмент. В определенных ситуациях – хорош. В некоторых – ужасен.
Будет ли работать скрам без доски? Легко. И доказано практикой. И вроде как, раз доска не является обязательным артефактом, можно будет продолжать называть скрам – скрамом.
Скрам-мастер
Кто такая эта чудо-роль? На что похожа?
Вариантов много. Например, скрам-мастер похож на тренера в спорте. Есть, допустим, футбольный клуб. Владелец продуктам там – менеджер, который определяет цели команды. Тренер – тот, кто помогает команде этих целей достигать.
В обычной, производственной среде, никаких тренеров нет – если бы так работал футбольный клуб, то начальник просто приходил бы в раздевалку перед матчем и говорил: «идите и выигрывайте». А когда проиграют, устраивал бы разнос. Кого-то выгонял, кому-то угрожал и т.д. Как на заводе.
А тренер, как и скрам-мастер, служит провайдером между командой и менеджером. Власти у тренера, конечно, побольше – он не лидер-слуга. Но и результат от него требуется более быстрый и понятный – никто не будет ждать, пока он там кого-то фасилитирует. Тренер, как и скрам-мастер, понимает, как должна функционировать команда, т.е. он те просто задачи ставит, а объясняет, как их надо решать. Налаживает связи, мотивирует, создает и поддерживает атмосферу и т.д.
Другая аналогия – командир взвода, спецназа какого-нибудь. Это – играющий тренер. На задания ходит вместе с подчиненными, точно так же решает боевые задачи. В свободное время – руководит подготовкой и повышением мастерства, освоением новой техники, физ.подготовкой. Разумеется, постоянно работает с командой в плане психологии – мотивирует, поддерживает, помогает. Своеобразными методами, конечно, иногда, но цель-то одна – максимальная боеспособность взвода.
Скрам-мастер, по сравнению с этими ребятами, халявщик. За результат не особо отвечает. Отсутствие формальной власти, вроде бы, воспринимается как преимущество – он же лидер-слуга, но на деле может перерасти в безответственность. Можно ведь до бесконечности фасилитировать, не оказывая никакого влияния на результат? А когда выгонят – искать другую команду, чтобы там фасилитировать.
Можно ли изменить или убрать роль скрам-мастера? Конечно. Например, объединить эту роль с владельцем продукта. Знаю, в Методике написано, что так лучше не делать – это помешает мастеру фасилитировать. Но, зато, добавит понятных целей и ответственности. Когда цель понятна и измерима, тогда и фасилитация превращается из необязательной, непонятной хрени во вполне конкретную, осязаемую обязанность, прямо влияющую на результат. Как у тренера или комвзвода.
Правда, тогда смысл называть его скрам-мастером потеряется. Это будет, наверное, тимлид – не забываем, что «лид» — это лидер. А лидер – это не только флаг в руках, но и работа с мотивацией, целями, умение увлечь за собой, привнесение новых методов работы, натаскивание компетенций и т.д. Драйвер команды, короче. И в смысле внутреннего развития, и в смысле достижения результата.
Если в скраме заменить мастера на тимлида, что произойдет? Скрамом это уже нельзя будет называть – одна из ключевых ролей выкинута. А на результате как скажется? А если вообще без скрам-мастера? Если его функции размазать по команде, как это рекомендовал сделать Белбин? Один фасилитирует, другой мотивирует, третий следит за исполнением правил. Вполне себе можно так жить.
Итого
Ну всё, дальше принцип понятен. Скрам, как и любая другая методика – это алгоритм, сотканный из компонентов, или инструментов. Кто его соткал? Ну, допустим, Джефф Сазерленд и Кен Швабер.
Представьте, что два парня, Джефф и Кен, создали некий компонент, приносящий неплохую пользу в разработке веб-приложений. Вы его нарыли в гитхабе, установили, попробовали – ого, прикольно! Работает! И правда, лучше стало!
А потом, в какой-то момент, вас в этом компоненте стало что-то раздражать. Например, вызов его методов кажется недостаточно полиморфным. Вы заходите в исходный код и обнаруживаете…
Чего вы там можете обнаружить? Да всё, что угодно. Например, заимствования, которые вам не понравятся. Или заимствованные компоненты будут правильными, но криво использованы. Или прямо указана конкретная версия хорошего компонента, а он хорошо развивается и давно стал в разы круче, но разработчики не хотят адаптировать вышестоящий компонент. Или обнаруживаете в алгоритме кусок приличного размера, неплохо так отжирающий ресурсы, но не несущий конкретно для вашего проекта никакой пользы.
Что будете делать? Каждый ответит что-то свое, конечно. Кто-то даже внутрь не полезет. Кто-то сделает форк и поправит то, что не нравится. Обретет, конечно, некоторые проблемы с обновлением. Хотя, не факт – такие штуки, как скрам, не меняются годами. Кто-то напишет разработчикам. Чего они ответят – не знаю.
Кто-то же просто возьмет исходные компоненты, и пересоберет их по-своему – так, как надо в конкретном проекте или продукте.
Точно так же можно поступать с любыми методиками. Хотел написать «можно и нужно», но не стал навязывать свое мнение – каждый ведь сам решает.
Закончить хочу цитатой Голдратта. Это, возможно, единственный из светил, разработавших какие-то методики, честно говоривший о необходимости их изменения, адаптации, компоновки и, главное, понимания принципов функционирования.
Существует разница между практическими методами и фундаментальными концепциями, на которых основаны эти методы. Концепции являются общими, практические методы – это адаптация концепций к конкретной среде. Как мы уже видели, подобная адаптация не является простой, и делает необходимой разработку определенных элементов решения. Что мы должны помнить – что подобное решение основано на исходных посылках (иногда — скрытых) о конкретной среде. Мы не должны ожидать, что это решение будет работать в среде, для которой эти исходные посылки не являются верными. Мы можем сэкономить множество усилий и избежать разочарования, если скрупулезно сформулируем эти исходные посылки.
Автор: Иван Белокаменцев
