Наш мир очень странный.
И чем дальше, тем страннее.
И вы поймете, что происходит. В мире есть инженеры и программисты.
Иногда в одном человеке.
Люди, которые понимают, что такое алгоритм.
Более того, люди, которые создают эти алгоритмы.
Прекрасно зная, что созданный алгоритм подходит для решения одной задачи, но не подходит для другой.
Они понимают, что если немного изменить алгоритм, он сможет решить сопутствующие проблемы.
Те, кто не гнушается выкинуть половину чужого алгоритма, чтобы он лучше решал текущую задачу.
Программисты создают решение проблемы или класса проблем.
В этом суть профессии.
Там, где это возможно, они используют готовые куски своего или чужого кода.
И у всех все хорошо.
Но как только дело доходит до создания алгоритмов вне компьютера, программисты вдруг теряют голову.
Я не говорю о рисовании схем алгоритмов на бумаге, как это было на экзамене в университете — с этим справится любой из нас.
Я говорю о «реализации методов», «работе над фреймворком», «обязательном использовании всех артефактов».
О сектах, короче.
Немного идиотизма
Все знают, что такое условный оператор.Без него нет жизни.
Ни один достойный алгоритм не сработает. Ни в компьютере, ни в жизни.
А теперь представьте: появился некий человек, скажем, Джон, и заметил, что в Бейсике есть условный оператор.
Я копнул глубже, разобрался и убедился, что оно есть, оно работает, и без этого я не могу.
Допустим, Джон глуп.
Но он решил завоевать мир.
Я пошел продавать Бейсик.
Не сам язык, а некая «крутая методология разработки ПО», центральным звеном которой является… И Джон вам ничего не расскажет, пока вы не пройдёте курс.
Ладно, нашлись люди, которым курсы понравились, тем более, что цена была не высокой.
Пришли, послушали, ахнули.
Основным элементом самой крутой техники разработки программного обеспечения является условный оператор.
Мы много слышали об условном операторе.
Например, как превратить его в оператор множественного выбора.
Они снова ахнули — какой мощный Условный Оператор.
Половину аудитории составляли программисты.
Они посмеялись и пошли домой.
Еще четверть составляли менеджеры.
Мы призадумались, задали вопросы, и кто-то решил реализовать эту классную технику у себя дома.
В последней четверти были такие люди, как Джон.
Они уговорили парня создать франшизу, Сообщество, Центр сертификации и Университет условного оператора.
Программисты вернулись к работе с курса, уже не помня об Условном Операторе.
Но через час пришли менеджеры и объявили, что разработка ПО теперь будет вестись самым крутым методом.
Да, речь идет об условном операторе.
В общем, лучше писать на БЕЙСИКЕ.
Робкие, а то и не робкие возражения программистов были проигнорированы.
Фразы типа «блин, это же условный оператор, оно везде» были восприняты как попытки покрасоваться.
Колесо начало вращаться.
И Джон быстро понял, что условного оператора недостаточно.
Еще должен быть Цикл, Подпрограмма, Переменная, Массив и т. д. Надо бы все это как-то назвать.
Одним словом.
Ох, пусть это будут Артефакты! Не больше, не меньше! Осталось главное: добавить в методологию пункт о том, что самый крутой метод разработки ПО — это целостные, целостные знания.
Это значит, что из него нельзя выкинуть ни одного куска.
И добавить к нему ничего нельзя — оно перестанет работать.
Делай как написано.
Благодаря энтузиазму Джона и его друзей, теперь весь мир использует не условный оператор, а Условный Оператор, не цикл, а Цикл и т.д., согласно списку.
Те, кто понял идиотизм ситуации, давно уволились или замолчали.
Новички твердо верят, что условный оператор — это часть самой крутой техники разработки программного обеспечения, созданной Джоном.
А все остальные условные операторы — жалкое подобие, выцветшая копия и кусок Знания, вырванный из контекста.
Любой, кто осмелится проголосовать в Интернете (или, не дай бог, внутри команды), будет подвергнут яростному осуждению и гневному минусу — смотри, валенок, ты не видишь преимуществ Условного оператора! А если несчастный попросит объяснить, в чем смысл и отличие условного оператора от условного оператора в С++, яваскрипте или даже 1С, он получит ответ «невозможно объяснить», «не поймешь» или «иди читай».
гид".
Инструменты и алгоритмы
Все понимают, что такое условный оператор и как его использовать в алгоритмах.Точно так же всем понятно, что такое, например, наклейка с письменным заданием.
Стикеры появились до Scrum и живут вне его.
Посмотрите на компьютер бухгалтера, поставщика или продавца.
Они еще не отвыкли вешать на монитор кучу стикеров со срочными задачами.
Пароль будет написан на одной из наклеек.
Любую технику можно легко разобрать на инструменты, принципы и связи.
Так же, как любой алгоритм разбивается на фигуры разной формы и назначения — начало и конец алгоритма, действие, условие, подпрограмму.
Любая техника имеет сферу применения.
Не все там абсолютно — есть более подходящая среда, есть меньше.
То же, что и с алгоритмами.
Изменения могут быть внесены в любой метод. Выбрасывайте детали, добавляйте новые, модифицируйте отдельные инструменты.
Точно так же, как алгоритмы.
Любые техники можно смешивать, целиком или по частям.
Возьмите половину от одного, четверть от другого и придумайте себе еще четверть.
Когда вы создаете приложение или сервис, для вас это очевидно.
Правда, остается вопрос: будет ли методология методологией, если ее изменить? Вот как, например, отвечает на этот вопрос известный Scrum Guide:
«Роли, артефакты, правила и события Scrum не могут быть изменены.Немного напоминает мне Джона и его условный оператор, не так ли? Вроде бы меняйте, если хотите, но это будет не Скрам.Хотя использование отдельных элементов этого фреймворка допустимо, полученный результат нельзя назвать Scrum. Скрам существует только как законченная структура, но он может включать в себя другие методы, методологии и практики».
А какой будет результат - хрен его знает. На всякий случай отметили, что можно попробовать что-нибудь запихнуть внутрь.
Но костяк должен остаться.
А иначе.
Даже страшно представить.
Неужели это так страшно? Что произойдет, если некоторые артефакты выбросить или заменить? И вообще, какой в них смысл? Откуда они пришли? Почему считается, что они работают только в такой комбинации, как решили авторы? Попробуем разобраться по частям.
Спринт и бэклог спринта
Отличный инструмент, кстати.Вероятно, изобретено тысячу лет назад. Его всегда называли по-разному, но, наверное, самым распространенным было «План».
А по-человечески – «выполнить определенный объем работы за определенный период времени».
Мне, как 1Снику, это более известно как объемное планирование (SCP).
Широко используется при планировании производства и продаж.
Например, план продаж менеджера, равный 1 миллиону рублей в месяц, — это бэклог и спринт. Иногда достаточно цифры, иногда есть разбивка по товарным группам, или ограничения на рынке сбыта, или даже есть конкретный перечень товаров, если того требует стратегия компании.
В производстве еще проще.
Втулки – 1000 шт., валы – 2000 шт., роторы – 500 шт. Это, скажем, недельный план.
Это тоже отставание от еженедельного спринта производственного участка.
Правда, не надо объяснять работникам, что это не план, а спринт. Инструмент хорош по сравнению с обычным дедлайн-менеджментом, когда пул задач программистов оценивается по трудозатратам, упорядочивается по какому-то критерию и каждой задаче назначается срок выполнения.
На производстве это называется сменным планированием, или цеховым планированием, на основе которого затем создаются производственные задания, содержащие перечень деталей и полуфабрикатов, технических операций, материалов, входов и выходов (где что взять и куда передать результат).
У программистов планирование цеха работает плохо, обсуждать нечего.
Время обработки детали на конкретной модели станка известно давно и достаточно точно.
Частота обслуживания такая же.
Оценена достаточность материалов.
Возьми и сделай это.
Вариации, мешающие выполнению плана, обычно не оказывают существенного влияния на массовое производство.
А если и есть, то есть отличные методы их анализа и устранения.
Варианты программиста гораздо сильнее.
Ведь он не машина, как бы этого ни хотелось некоторым менеджерам, пришедшим в ИТ из продаж или производства.
Поэтому планирование мастер-класса (задача+срок) не подходит программисту.
Вот что придумали умные люди — нужно подниматься на уровень выше, не планировать выполнение поминутно, а давать объём за период. Просто придумали другое название — спринт и бэклог.
Заполнение графика объемов производства основано на принципах, аналогичных формированию бэклога спринта.
Есть даже такое понятие – «набрать план».
Есть потребности одного и того же отдела продаж (= большой задел), есть пропускная способность производства (= возможности команды в цифрах), плюс есть четкие критерии отбора – объем продаж, рентабельность каждой позиции, параметры клиента (например , условия оплаты).
Вы вбиваете производственный план и сразу видите, какой примерный финансовый результат получите.
Это не эфемерный «релиз».
Есть ли недостатки у этого инструмента? Конечно, как и любой другой.
Если разобраться, бэклог спринта — это то же самое, что планирование цеха, только без структурированной последовательности решения проблем.
Поэтому у всех задач один и тот же срок — окончание спринта.
Поскольку у задач только один дедлайн, появляется неприятный эффект — в начале спринта активность может быть существенно ниже, чем в конце.
Так устроена любая человеческая психология.
Всегда хочется возиться в начале периода выполнения, будь то одна задача или невыполненная работа.
Отдохните от последнего периода, особенно от его заключительной части, когда нам нужно было показать колоссальный результат. Есть, конечно, стабильные и ритмичные люди, которые всю неделю работают с одинаковой скоростью, но большинство начинают «нормально работать» где-то в среду.
Можно ли обойтись без спринта и его бэклога? Легко.
Например, с помощью инструмента «как можно быстрее».
В общем, это не прапорщинская манера, а вполне нормальная стратегия планирования того же цеха (Как можно скорее, как можно скорее).
Означает, что выпуски будут «прикреплены» к началу периода времени, т. е.
к понедельнику, а не к пятнице, как в случае со стратегией планирования «Как можно дольше» (ALAP).
Планирование как таковое в данном случае не требуется.
Есть бэклог продукта, есть приоритеты, есть правило «как можно быстрее».
Вы берете первый и делаете это.
Закончили – берите второй.
И так – от забора до обеда.
Спринт, а точнее его суть, т. е.
период времени, который можно оставить для понимания и анализа результативности (неделя за неделей, месяц за месяцем и т. д.).
Есть ли недостатки у стратегии «как можно быстрее»? Конечно, миллион.
Во-первых, человек может быстро устать.
Во-вторых, он почувствует себя машиной.
В-третьих, он, скорее всего, убежит — там, где используются обычные бэклог-спринты.
Или просто ставят задачи и ждут результата.
В общем, где тише? Но практика показывает, что жить «как можно быстрее» годами вполне возможно, если здраво понимать, что это стратегия планирования, а не потогонная работа.
Можно ли выкинуть спринт и его бэклог? Нет. Не потому, что это уникальные изобретения того же Скрама, а потому, что это естественный способ планирования, которым в той или иной форме пользуется каждый.
Вариаций много, но принцип один – нужно выполнить определенный объем работы за определенный период времени.
Является ли такой инструмент, как спринт, уникальным и ключевым элементом любой методологии? Нет. Это то же самое, что сказать, что набор кода на клавиатуре — это уникальное изобретение какой-то техники.
Почти все тексты набираются на клавиатуре.
Скрам-доска
Формально доска — это не артефакт и не правило, но, думаю, о ней тоже стоит поговорить, потому что среди людей существует достаточно очевидная закономерность: Scrum — это доска с стикерами.Тут вообще сами все понимаете.
Доска с стикерами и написанными на ней задачами не является чем-то уникальным.
Это, грубо говоря, кроссплатформенный инструмент. Моя жена иногда клеит на холодильник наклейки со списками дел, хотя о Scrum ничего не знает. Этот инструмент хорош? Это зависит от того, с чем вы это сравниваете.
Да, наверное, хорошо.
Например, он позволяет быстро оценить и просмотреть пул задач.
На компьютере, или любом другом электронном устройстве, задачи нужно листать – на одном экране обычно все не умещается.
Поэтому одним взглядом – тоже.
Еще один важный плюс – общая доступность для команды.
Вы можете подойти и посмотреть в любое время; вам не придется заходить в какую-то систему, искать, делать выбор и т.д. Многим нравится невиртуальный характер доски.
Ведь на компьютере все виртуально, руками потрогать нельзя.
А здесь – пожалуйста, хотя бы облизывайте.
Некоторым в этом отношении нравятся пробковые доски.
Разница примерно такая же, как между бумажными и электронными книгами.
Конкретно для Скрам-доски можно отметить такое преимущество, как разделение на две части — в работе и завершено.
Повседневное обращение с наклейками предполагает выбрасывание уже готовых — не очень хорошо, потому что.
прогресс менее заметен.
Есть ли недостатки у Scrum-доски? Конечно.
Как и любая доска.
Начнем с бытовых – черновики, некачественные наклейки, плохой почерк, саботаж.
Результат – потерянные задачи и неразбериха в управлении.
На доске прогресс не очень заметен.
В целом для спринта – да.
На сегодня, вчера - нет. Отсюда необходимость ежедневных дискуссий.
В частности, на Scrum-доске не виден статус задач, если жизнь сложнее «запланировано» — «выполнено».
Канбан-доска выглядит предпочтительнее.
Доска не позволяет нормально работать, если команда территориально распределена.
Поэтому и появляются электронные доски.
«Электронная доска, мне кажется, — верный признак сектантства.
Она потеряла все преимущества обычной, но, по неизвестной причине, ею продолжают пользоваться.
Наверное, просто потому, что это доска.
Часть Методики.
В общем, инструмент – это всего лишь инструмент. В определенных ситуациях это хорошо.
В некоторых это ужасно.
Будет ли Scrum работать без доски? Легко.
И доказано практикой.
И похоже, что поскольку доска не является обязательным артефактом, то можно будет и дальше называть Scrum — Scrum.
Скрам-мастер
Кто эта чудо-роль? Как это выглядит? Есть много вариантов.Например, Scrum Master похож на тренера в спорте.
Есть, например, футбольный клуб.
Владельцем продукта там является менеджер, который определяет цели команды.
Тренер – это тот, кто помогает команде достичь этих целей.
В нормальной производственной среде нет тренеров — если бы футбольный клуб работал так, начальник просто пришёл бы в раздевалку перед матчем и сказал: «Иди и побеждай».
А когда они проигрывали, он их ругал.
Кого-то выгнал, кому-то угрожал и т. д. Как на заводе.
А коуч, как и Скрам-мастер, выступает посредником между командой и менеджером.
У тренера, конечно, больше власти – он не лидер-слуга.
Но и результат от него должен быть быстрее и понятнее — никто не будет ждать, пока он там кого-то облегчит. Коуч, как и Скрам-мастер, понимает, как должна функционировать команда, т.е.
он просто ставит проблемы и объясняет, как их следует решать.
Устанавливает связи, мотивирует, создает и поддерживает атмосферу и т. д. Другая аналогия – командир взвода, какого-то спецназа.
Это играющий тренер.
Он ходит на задания вместе со своими подчиненными и таким же образом решает боевые задачи.
В свободное время занимается подготовкой и повышением квалификации, освоением новых методик, физической подготовкой.
Конечно, он постоянно работает с командой в плане психологии – мотивирует, поддерживает, помогает. Своеобразными методами, конечно, иногда, но цель одна – максимальная боеспособность взвода.
Скрам-мастер по сравнению с этими ребятами — нахлебник.
Не несет особой ответственности за результат. Отсутствие формального авторитета вроде бы воспринимается как преимущество – он руководитель-слуга, но на деле это может перерасти в безответственность.
Можно ли фасилитировать бесконечно, не влияя при этом на результат? А когда тебя выгонят, ищи там другую команду, которая будет фасилитировать.
Можно ли изменить или удалить роль Scrum Master? Конечно.
Например, объедините эту роль с владельцем продукта.
Я знаю, что в Методике сказано, что лучше этого не делать – это помешает мастеру облегчить работу.
Но, с другой стороны, это добавит четких целей и ответственности.
Когда цель ясна и измерима, то фасилитация превращается из необязательной, непонятной хрени в вполне конкретную, осязаемую ответственность, напрямую влияющую на результат. Как инструктор или командир взвода.
Правда, тогда смысл называть его Скрам-мастером потеряется.
Вероятно, это будет тимлид — не забывайте, что «лид» — это лидер.
А лидер – это не только флаг в руках, но и работа с мотивацией, целями, умением увлекать других, внедрением новых методов работы, обучением компетенций и т. д. Водитель команды, короче.
И в смысле внутреннего развития, и в смысле достижения результата.
Если в Scrum заменить мастера на тимлида, что произойдет? Это уже нельзя называть Scrum — одна из ключевых ролей выброшена.
Как это повлияет на результат? Что делать, если Скрам-мастера вообще нет? Что, если его функции будут распределены по всему командованию, как рекомендовал Белбин? Один помогает, другой мотивирует, третий следит за выполнением правил.
Жить так вполне возможно.
Общий
Ну вот и все, тогда принцип ясен.Scrum, как и любая другая методология, представляет собой алгоритм, сотканный из компонентов или инструментов.
Кто это сплел? Ну, скажем, Джефф Сазерленд и Кен Швабер.
Представьте себе, что два парня, Джефф и Кен, создали некий компонент, который приносит хорошую пользу при разработке веб-приложений.
Вы откопали это на Github, установили, попробовали — ух ты, круто! Работает! Действительно, стало лучше! И потом, в какой-то момент, что-то в этом компоненте начало тебя раздражать.
Например, вызов его методов кажется недостаточно полиморфным.
Вы заходите в исходный код и находите.
Что вы можете там найти? Да что угодно.
Например, взять взаймы то, что вам не понравится.
Или заимствованные компоненты будут правильными, но использованы неправильно.
Или прямо указана конкретная версия хорошего компонента, но он хорошо развивается и уже давно стал намного круче, а разработчики не хотят адаптировать родительский компонент. Или вы обнаруживаете в алгоритме приличный по размеру кусок, который довольно хорошо съедает ресурсы, но не приносит никакой пользы конкретно вашему проекту.
Что вы будете делать? Конечно, у каждого будет свой ответ. Некоторые даже не проникнут внутрь.
Кто-то сделает вилку и исправит то, что ему не нравится.
Конечно, с обновлением будут некоторые проблемы.
Хотя, это не факт — такие вещи, как Scrum, не меняются уже много лет. Кто-нибудь напишет разработчикам.
Я не знаю, что они ответят. Кто-то просто возьмет оригинальные компоненты и соберет их по-своему — так, как нужно для конкретного проекта или продукта.
То же самое можно сделать любым методом.
Хотел написать «можно и нужно», но не навязывал своего мнения – каждый решает сам.
Я хотел бы закончить цитатой Голдратта.
Это, пожалуй, единственный из корифеев, разработавших какие-то методы, который честно говорил о необходимости их изменить, адаптировать, скомпоновать и, главное, понять принципы их функционирования.
Существует разница между практическими методами и фундаментальными концепциями, на которых основаны эти методы.Теги: #Управление разработкой #Управление проектами #Управление персоналом #agile #черт знает что #этот идиот снова что-то написал #этот идиот снова что-то написал #этот идиот снова что-то написал #этот идиот снова что-то написалКонцепции являются общими, практика заключается в адаптации концепций к конкретной среде.
Как мы уже видели, такая адаптация непроста и требует разработки определенных элементов решения.
Мы должны помнить, что такое решение основано на первоначальных предположениях (иногда скрытых) о конкретной среде.
Нам не следует ожидать, что это решение будет работать в среде, для которой эти предположения не верны.
Мы можем сэкономить массу усилий и разочарований, если тщательно сформулируем эти предпосылки.
-
Пульсометры Для Nasa: Знакомимся С Salutron
19 Oct, 24 -
Самая Сложная Программа
19 Oct, 24 -
Подкаст Unclesoky – Эпизод №13
19 Oct, 24
