Как сбежать из секты?

    Наш мир устроен очень странно. И чем дальше, тем становится страннее. И хрен поймешь, в чем дело.

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

    Но, как только дело доходит до создания алгоритмов за пределами компьютера, программисты вдруг теряют голову. Я не говорю о рисовании схем алгоритмов на бумаге, как это было на экзамене в универе – тут любой из нас справится.

    Я говорю о «внедрении методик», «работе по фреймворку», «обязательном использовании всех артефактов». О сектах, короче.

    Немного идиотизма


    Все знают, что такое условный оператор. Без него нет никакой жизни. Ни один приличный алгоритм работать не будет. Ни в компьютере, ни в жизни.

    А теперь представьте: появился некий человек, допустим – Джон, и заметил, что в бейсике есть условный оператор. Поковырялся, разобрался, убедился – есть, работает, без него никак.

    Допустим, Джон – туповат. Но решил покорить мир. Пошел продавать Бейсик. Не сам язык, а некую «крутейшую методику разработки программного обеспечения», центральным звеном которой является… А не скажет Джон, пока курс не пройдете.

    Ладно, нашлись любители курсов, тем более, что цена не высока. Пришли, послушали, ахнули. Главным элементом крутейшей методики разработки программного обеспечения является Условный Оператор. Много послушали про условный оператор. Например, о том, как превратить его в оператор множественного выбора. Еще раз ахнули – какой могучий Условный Оператор.

    Половину аудитории составляли программисты. Поржали, ушли домой. Еще четверть составляли менеджеры. Призадумались, позадавали вопросы, кто-то решил внедрить эту крутейшую методику у себя. Последнюю четверть составляли такие же, как Джон. Они уговорили парня на создание франшизы, Сообщества, Центра Сертификации и Университета Условного Оператора.

    Программисты с курса вернулись на работу, уже не помня об Условном Операторе. Но через час пришли менеджеры и объявили, что теперь разработка ПО будет вестись по крутейшей методике. Да, которая про Условный Оператор. И вообще, писать лучше на бейсике.

    Робкие, а то и не робкие возражения программистов были проигнорированы. Фразы типа «блин, это условный оператор, он везде есть» были восприняты как попытки повыпендриваться. Колесо закрутилось.

    А Джон быстро понял, что мало одного Условного Оператора. Еще должен быть Цикл, Подпрограмма, Переменная, Массив и т.д. Надо бы как-то все это назвать… Одним словом… О, пусть это будут Артефакты! Ни больше, ни меньше!

    Осталось главное: внести в методику пункт о том, что крутейшая методика разработки программного обеспечения – это целостное, холистическое знание. Значит, из него нельзя выкинуть ни одного куска. И в него нельзя ничего добавлять – работать перестанет. Как написано, так и делай.

    Благодаря энтузиазму Джона и его друзей теперь весь мир пользуется не условным оператором, а Условным Оператором, не циклом, а Циклом, и т.д., по списку. Те, кто понимал идиотизм ситуации, давно ушли на пенсию или заткнулись. Те, кто пришел недавно, свято верят, что Условный Оператор – это часть крутейшей методики разработки программного обеспечения, созданной Джоном. А все остальные условные операторы – жалкое подобие, блеклая копия и выдранный из контекста кусок Знания.

    Любой, кто посмеет подать голос в интернете (или, не дай-то Бог, внутри команды), будет подвергнут яростному осуждению и гневному минусованию – ишь ты, валенок, не видишь преимуществ Условного Оператора! А если несчастный попросит объяснить, в чем смысл и отличие от условного оператора в C++, javascript или даже 1С, получит в ответ «это невозможно объяснить», «тебе не понять», или «иди читай гайд».

    Инструменты и алгоритмы


    Все понимают, что такое условный оператор, и как его использовать в алгоритмах. Точно так же все понимают, что такое, например, стикер с записанной задачей. Стикеры появились до скрама, и живут вне его. Посмотрите на компьютер бухгалтера, снабженца или продавца. Они еще не изжили привычку вешать на монитор кучу стикеров со срочными задачами. На одном из стикеров будет написан пароль.

    Любая методика легко разбирается на инструменты, принципы и связи. Так же, как любой алгоритм разбирается на фигурки разных форм и назначения – начало и конец алгоритма, действие, условие, подпрограмма.

    Любая методика имеет область применения. Не всё там абсолютно – есть более подходящая среда, есть – менее. Так же, как и у алгоритмов.

    В любую методику можно вносить изменения. Выкидывать куски, добавлять новые, модифицировать конкретные инструменты. Так же, как и алгоритмы.

    Любые методики можно миксовать, целиком или по кускам. Взять половину от одной, четверть от другой, еще четверть – выдумать самостоятельно. Когда вы создаете приложение или сервис, для вас это очевидно.

    Правда, остается вопрос – будет ли методика методикой, если ее поменять?

    Вот как отвечает на этот вопрос, например, широко известный Scrum Guide:
    «Роли, артефакты, правила и события Скрама не подлежат изменению. Хотя использование отдельных элементов данного фреймворка допустимо, но полученный результат не может называться Скрамом. Скрам существует только в качестве цельного фреймворка, но он может вмещать в себя другие техники, методологии и практики.»
    Немного напоминает Джона и его Условный Оператор, не правда ли? Вроде как, меняйте, если хотите, только это будет не скрам. И каков будет результат – хрен его знает. На всякий случай отметили, что внутрь можно попробовать чего-то засунуть. Но костяк должен оставаться. Иначе… Даже страшно представить.

    Так ли уж страшно? Что будет, если часть артефактов выкинуть или заменить? И вообще, какой в них смысл? Откуда они взялись? Почему считается, что они работают только в таком сочетании, как решили авторы?

    Попробуем разобраться по частям.

    Спринт и Бэклог Спринта


    Отличный инструмент, кстати. Изобретен, наверное, лет тысячу назад. Только назывался всегда по-разному, но самое, наверное, распространенное – «План». А по-человечески – «сделать определенный объем работы за определенный промежуток времени».

    Мне, как 1Снику, он больше известен, как объемно-календарное планирование (ОКП). Широко применяется при планировании производства и продаж. Например, план продаж менеджера, равный 1 млн. рублей в месяц – это бэклог и спринт. Иногда достаточно цифры, иногда бывает разбивка по группам продукции, или ограничения по рынку сбыта, или даже есть конкретный перечень номенклатуры, если того требует стратегия компании.

    В производстве еще проще. Втулок – 1000 шт, валов – 2000 шт, роторов – 500 шт. Это, допустим, недельный план. Он же – бэклог недельного спринта производственного участка. Правда, рабочим можно не объяснять, что это – не план, а спринт.

    Инструмент хорош в сравнении с распространенным управлением по срокам, когда пул задач программистов оценивается по трудозатратам, упорядочивается по какому-либо критерию, и у каждой задачи рождается срок выполнения. В производстве это называется посменным, или цеховым планированием, из которого потом создаются задания на производство, содержащие перечень деталей и полуфабрикатов, тех.операций, материалов, входов и выходов (где что взять и куда передать результат).

    Для программистов цеховое планирование работает плохо, тут и обсуждать нечего. Время обработки детали на конкретной модели станка известно давно и достаточно точно. Периодичность обслуживания – тоже. Достаточность материалов оценена. Бери и делай. Вариации, мешающие выполнению плана, в серийном производстве обычно не оказывают значительного влияния. А если оказывают – есть прекрасные методы для их анализа и устранения.

    Вариации программиста намного сильнее. Он ведь – не станок, как бы того не хотелось некоторым менеджерам, пришедшим в ИТ из продаж или производства. Поэтому цеховое планирование (задача + срок) для программиста не годятся. Вот и придумали толковые люди – надо подняться на уровень выше, не расписывать исполнение по минутам, а дать объем на период. Только название другое придумали – спринт и бэклог.

    Наполнение объемно-календарного плана производства строится по принципам, схожим с формированием бэклога спринта. Даже есть такое понятие – «набрать план». Есть потребности того же отдела продаж (= большой бэклог), есть пропускная способность производства (= возможности команды в цифрах), плюс есть понятные критерии выбора – сумма продаж, рентабельность каждой позиции, параметры заказчика (например, условия оплаты). Набрал план производства – и сразу видишь, какой примерный финансовый результат получишь. Это не эфемерный «релиз».

    Есть ли недостатки у этого инструмента? Разумеется, как и у любого другого.

    Если разобраться, бэклог спринта – то же цеховое планирование, только без выстроенной последовательности решения задач. Поэтому у всех задач один срок выполнения – конец спринта. Раз срок у задач один, то появляется неприятный эффект – в начале спринта активность может быть значительно ниже, чем в его конце.

    Так работает любая человеческая психология. Всегда хочется поваландаться в начале периода исполнения, будь то одна задача, или бэклог. Отдохнуть от прошлого периода, особенно – от его финальной части, когда пришлось выдать «на гора» колоссальный результат. Есть, конечно, люди стабильные и ритмичные, работающие всю неделю на одной скорости, но большинство начинает «нормально работать» где-то в среду.

    Можно ли обойтись без спринта и его бэклога? Легко.

    Например, применив инструмент «как можно быстрее». Вообще, это не прапорская замашка, а вполне себе нормальная стратегия того же цехового планирования (As Soon As Possible, ASAP). Означает, что выпуски будут «прилипать» к началу отрезка времени, т.е. к понедельнику, а не к пятнице, как при стратегии планирования «точно к сроку» (As Last As Possible, ALAP).

    Планирование, как таковое, в этом случае не нужно. Есть бэклог продукта, есть приоритеты, есть правило «как можно быстрее». Берешь первую и делаешь. Закончил – берешь вторую. И так – от забора до обеда. Спринт, а точнее – его сущность, т.е. отрезок времени, можно оставить для понимания и анализа производительности (неделя к неделе, месяц к месяцу, и т.д.).

    Есть ли недостатки у стратегии «как можно быстрее»? Конечно, миллион. Во-первых, человек может быстро устать. Во-вторых, он будет чувствовать себя станком. В-третьих, он, скорее всего, сбежит – туда, где используются обычные спринты с бэклогом. Или просто ставят задачи и ждут результата. В общем, где поспокойнее. Но практика показывает, что и «как можно быстрее» вполне можно жить годами, если здраво понимать, что это стратегия планирования, а не потогонка.

    Можно ли выкинуть спринт и его бэклог? Нет. Не потому, что это – уникальные придумки того же скрама, а потому, что это естественный способ планирования, которым, в той или иной форме, пользуются все. Вариаций много, принцип один – нужно сделать определенный объем работы за определенный промежуток времени.

    Является ли такой инструмент, как спринт, уникальным и ключевым элементом какой-либо методики? Нет. Это всё равно, что утверждать, будто набор кода на клавиатуре – уникальная придумка какой-то методики. Почти все тексты набираются на клавиатуре.

    Скрам-доска


    Формально, доска не является артефактом или правилом, но, думаю, про нее тоже стоит поговорить, потому что есть среди людей довольно явный паттерн: скрам – это доска со стикерами.

    Тут, в общем-то, вы сами всё понимаете. Доска со стикерами, на которых записаны задачи, не является чем-то уникальным. Это, грубо говоря, кроссплатформенный инструмент. У меня жена на холодильник иногда стикеры лепит со списками дел, хотя ничего не знает ни про какой скрам.

    Хорош ли этот инструмент? Смотря с чем сравнивать. Да, пожалуй, хорош.

    Например, он позволяет быстро оценить, окинуть взглядом пул задач. В компьютере, или любом другом электронном устройстве, задачи нужно листать – в один экран всё, обычно, не помещается. Следовательно, в один взгляд – тоже.

    Еще важный плюс – общая доступность для команды. В любой момент можно подойти и посмотреть, не надо заходить в какую-то систему, искать, делать выборку и т.д.

    Многим нравится невиртуальность доски. В компьютере ведь все – виртуальное, руками не потрогаешь. А тут – пожалуйста, хоть облизывай. Некоторые, в этой связи, любят пробковые доски. Разница – примерно как между бумажными и электронными книгами.

    Конкретно для скрам-доски можно отметить такое преимущество, как разделенность на две части – в работе и выполнено. Бытовое обращение со стикерами предполагает выкидывание тех, что уже завершены – не очень хорошо, т.к. прогресс виден хуже.

    Есть ли недостатки у скрам-доски? Конечно. Как и у любой доски.

    Начать с бытовых – сквозняки, некачественные стикеры, плохой почерк, саботаж. В результате – потерянные задачи и неразбериха в управлении.

    По доске не очень виден прогресс. В целом за спринт – да. За сегодня, вчера – нет. Отсюда необходимость в ежедневных обсуждениях.

    Конкретно по скрам-доске не видны статусы задач, если жизнь сложнее, чем «запланировано» — «сделано». Предпочтительнее выглядит канбан-доска.

    Доска не позволяет нормально работать, если команда территориально распределена. Поэтому появляются электронные доски.

    Электронная доска, как мне кажется, верный признак сектанства. Она потеряла все преимущества обычной, но, по какой-то неведомой причине, ей продолжают пользоваться. Вероятно, просто потому, что это – доска. Часть Методики.

    В общем, инструмент, как инструмент. В определенных ситуациях – хорош. В некоторых – ужасен.

    Будет ли работать скрам без доски? Легко. И доказано практикой. И вроде как, раз доска не является обязательным артефактом, можно будет продолжать называть скрам – скрамом.

    Скрам-мастер


    Кто такая эта чудо-роль? На что похожа?

    Вариантов много. Например, скрам-мастер похож на тренера в спорте. Есть, допустим, футбольный клуб. Владелец продуктам там – менеджер, который определяет цели команды. Тренер – тот, кто помогает команде этих целей достигать.

    В обычной, производственной среде, никаких тренеров нет – если бы так работал футбольный клуб, то начальник просто приходил бы в раздевалку перед матчем и говорил: «идите и выигрывайте». А когда проиграют, устраивал бы разнос. Кого-то выгонял, кому-то угрожал и т.д. Как на заводе.

    А тренер, как и скрам-мастер, служит провайдером между командой и менеджером. Власти у тренера, конечно, побольше – он не лидер-слуга. Но и результат от него требуется более быстрый и понятный – никто не будет ждать, пока он там кого-то фасилитирует. Тренер, как и скрам-мастер, понимает, как должна функционировать команда, т.е. он те просто задачи ставит, а объясняет, как их надо решать. Налаживает связи, мотивирует, создает и поддерживает атмосферу и т.д.

    Другая аналогия – командир взвода, спецназа какого-нибудь. Это – играющий тренер. На задания ходит вместе с подчиненными, точно так же решает боевые задачи. В свободное время – руководит подготовкой и повышением мастерства, освоением новой техники, физ.подготовкой. Разумеется, постоянно работает с командой в плане психологии – мотивирует, поддерживает, помогает. Своеобразными методами, конечно, иногда, но цель-то одна – максимальная боеспособность взвода.

    Скрам-мастер, по сравнению с этими ребятами, халявщик. За результат не особо отвечает. Отсутствие формальной власти, вроде бы, воспринимается как преимущество – он же лидер-слуга, но на деле может перерасти в безответственность. Можно ведь до бесконечности фасилитировать, не оказывая никакого влияния на результат? А когда выгонят – искать другую команду, чтобы там фасилитировать.

    Можно ли изменить или убрать роль скрам-мастера? Конечно. Например, объединить эту роль с владельцем продукта. Знаю, в Методике написано, что так лучше не делать – это помешает мастеру фасилитировать. Но, зато, добавит понятных целей и ответственности. Когда цель понятна и измерима, тогда и фасилитация превращается из необязательной, непонятной хрени во вполне конкретную, осязаемую обязанность, прямо влияющую на результат. Как у тренера или комвзвода.

    Правда, тогда смысл называть его скрам-мастером потеряется. Это будет, наверное, тимлид – не забываем, что «лид» — это лидер. А лидер – это не только флаг в руках, но и работа с мотивацией, целями, умение увлечь за собой, привнесение новых методов работы, натаскивание компетенций и т.д. Драйвер команды, короче. И в смысле внутреннего развития, и в смысле достижения результата.

    Если в скраме заменить мастера на тимлида, что произойдет? Скрамом это уже нельзя будет называть – одна из ключевых ролей выкинута. А на результате как скажется? А если вообще без скрам-мастера? Если его функции размазать по команде, как это рекомендовал сделать Белбин? Один фасилитирует, другой мотивирует, третий следит за исполнением правил. Вполне себе можно так жить.

    Итого


    Ну всё, дальше принцип понятен. Скрам, как и любая другая методика – это алгоритм, сотканный из компонентов, или инструментов. Кто его соткал? Ну, допустим, Джефф Сазерленд и Кен Швабер.

    Представьте, что два парня, Джефф и Кен, создали некий компонент, приносящий неплохую пользу в разработке веб-приложений. Вы его нарыли в гитхабе, установили, попробовали – ого, прикольно! Работает! И правда, лучше стало!

    А потом, в какой-то момент, вас в этом компоненте стало что-то раздражать. Например, вызов его методов кажется недостаточно полиморфным. Вы заходите в исходный код и обнаруживаете…

    Чего вы там можете обнаружить? Да всё, что угодно. Например, заимствования, которые вам не понравятся. Или заимствованные компоненты будут правильными, но криво использованы. Или прямо указана конкретная версия хорошего компонента, а он хорошо развивается и давно стал в разы круче, но разработчики не хотят адаптировать вышестоящий компонент. Или обнаруживаете в алгоритме кусок приличного размера, неплохо так отжирающий ресурсы, но не несущий конкретно для вашего проекта никакой пользы.

    Что будете делать? Каждый ответит что-то свое, конечно. Кто-то даже внутрь не полезет. Кто-то сделает форк и поправит то, что не нравится. Обретет, конечно, некоторые проблемы с обновлением. Хотя, не факт – такие штуки, как скрам, не меняются годами. Кто-то напишет разработчикам. Чего они ответят – не знаю.

    Кто-то же просто возьмет исходные компоненты, и пересоберет их по-своему – так, как надо в конкретном проекте или продукте.

    Точно так же можно поступать с любыми методиками. Хотел написать «можно и нужно», но не стал навязывать свое мнение – каждый ведь сам решает.

    Закончить хочу цитатой Голдратта. Это, возможно, единственный из светил, разработавших какие-то методики, честно говоривший о необходимости их изменения, адаптации, компоновки и, главное, понимания принципов функционирования.
    Существует разница между практическими методами и фундаментальными концепциями, на которых основаны эти методы. Концепции являются общими, практические методы – это адаптация концепций к конкретной среде. Как мы уже видели, подобная адаптация не является простой, и делает необходимой разработку определенных элементов решения. Что мы должны помнить – что подобное решение основано на исходных посылках (иногда — скрытых) о конкретной среде. Мы не должны ожидать, что это решение будет работать в среде, для которой эти исходные посылки не являются верными. Мы можем сэкономить множество усилий и избежать разочарования, если скрупулезно сформулируем эти исходные посылки.
    Поддержать автора
    Поделиться публикацией

    Комментарии 21

      +2

      Скрам-мастер на производстве — это собственно мастер участка. Оттуда название и взято. Он именно что "нянчит" (т.е. активно фасилитирует) рабочих и отвечает за налаженность рабочего процесса. Бывает и "играющий мастер" — который сам за станком стоит (но это редкость — обычно на небольших специализированных участках).

        +1
        любой алгоритм разбирается на фигурки разных форм и назначения – начало и конец алгоритма, действие, условие, подпрограмма.

        если строго, то не «разбирается на», а «собирается из».
        Ведь не ищется способ разбиения на любые, произвольные части, а ищется способ, как собрать из заранее определенных частей.
          0
          Сверху-вниз Vs снизу вверх.
          +2
          Управлять и принимать решения должны инженеры, а не манагеры.
          То есть манагеры и управленцы должны быть из числа инженеров.
          Если вы это не понимаете и соглашаетесь так работать — не жалуйтесь на такую жизнь.
            +1
            манагеры и управленцы могут быть из числа инженеров, но не должны…
            иначе по программам MBA выпускались бы инженеры
            с обязательным изучением сопромата, черчения и прочих инженерных предметов
              0
              нет, они должны быть из числа инженеров
              то есть они должны быть разработчиками, например бывшими

              а у нас кто-попало руководит инженерами
              проблема в этом

              страной должны управлять инженеры, а не бухгалтеры, экономисты, маркетологи…
                0
                а у нас кто-попало руководит инженерами
                «Эти люди считают что девять женщин им родят ребёнка за месяц» — вольная интерпретация цитаты Уоррена Баффетта
              +1
              Управление людьми — это умение, совершенно отличное от инженерных умений — логики и умения разрабатывать/управлять механизмами (считая и компьютерные программы). Управлять людьми сложно, потому что у людей есть свои побуждения, часто не то что невербализуемые, но даже неосознаваемые. «Чего-то хочу эдакого, не знаю чего», «не нравится мне это, задницей чую».
              Можно быть отличным инженером и вообще никаким управленцем, сколько раз такое в истории случалось.
              Но, чтобы быть отличным управленцем, принимающим решения, нужно, конечно, понимание предметной области.
            • НЛО прилетело и опубликовало эту надпись здесь
                0
                Непонятно, зачем статья, точнее, зачем нападки на методику, авторы Скрама имеют право сказать, что их методика не должна изменяться путем выкидывания элементов, иначе теряет право именоваться скрамом. Что вы и признаете в начале и в конце статьи, кстати. При изменении ингредиентов будет какая-то другая методика. Кто ж спорит.
                Непонятно зачем нападать на скрам, он же тупо инструмент.
                Может проблема в карго-культе?
                  +1

                  Нападают не на скрам, нападают на сектантов, одержимых горе-менеджеров. А скрам тут, это уместный, яркий и показательный пример.
                  Статья порадовала… Убыл поискать другие примеры разделения фундаментальных принципов и практических реализаций, это полезно.

                    0
                    Самые яркие — это фундаментальный принцип коммунизма и его реальные реализации, и то же самое про капитализм.
                      +1

                      Да уж Пол Пот — не даст соврать. Но зачем так углубляться в политку? Самые обычные секты (вроде "бога Кузи") — это оно и есть по определению. И религиозные и торговые. Кирби — не такой уж и плохой пылесос, и Цептер — не плохая посуда. Но вот продвижение и "реализация" — ужасны.

                  0
                  Немного напоминает Джона и его Условный Оператор, не правда ли? Вроде как, меняйте, если хотите, только это будет не скрам.

                  Неправильно. Это будет не Скрам ©. Case-sensitive.

                    +1
                    Вся проблема в том, что глупые люди, которые волею судьбы руководят группами умных людей… вместо того чтобы становиться умнее, пытаются компенсировать недостаток ума чужими готовыми методиками, инструментами, решениями и т.д. Без понимания сути (ума не хватает!), но с «пониманием» эффективности (другим вон как помогло!).

                    Это называется культ карго. Есть еще один анекдот, прямо как раз про скрам:

                    Средняя полоса России. Зима. На реке мужик ожесточенно молотит веслом по замерзшему льду. Удивленный прохожий его спрашивает:
                    — Ты что делаешь?
                    — Как что? Синих крокодилов отпугиваю.
                    — Да не было здесь отродясь никаких синих крокодилов!
                    — Вот потому и не было, что хорошо отпугиваю.


                    Единственное, что все-таки можно сказать в защиту скрама, что если тех же дураков заставить внедрять RUP, получится еще хуже ))). Кстати, если их спросить чем они отличаются, и не скажут. Ну, кроме заклинаний секты про «работающий продукт наше фсе», а про «неформальные отношения» как важную ценность, лучше даже не вспоминать.

                    А при грамотном подходе любые методики должны всегда адаптироваться под конкретные нужды и окружение. В этом их смысл. Важно просто в них разбираться, а уж если не понял чего, так честно признаться в этом себе — а не действовать в стиле «пилите гирю, она золотая». В надежде, что рано или поздно прилетят самолеты с Дарами.

                      +1

                      Ума на всех у всех никогда не хватит. Слепо пользоваться наработанными методиками — нормально (много людей задумываются почему унитаз и процесс справления надобностей устроены именно так?). Это банальное разделение труда — одни люди тратят время на на то, чтобы многие другие люди тратили времени меньше и прикладывали свой ум к предметной области, а не к организации труда.


                      Что не нормально — это приписывать своим методикам несуществующую универсальность (или другие несуществующие качества), играя на грешном стремлении людей к халяве. Или, что тоже самое, просто не очерчивать круг задач и условий в которых методика эффективна и не прописывать явно и чётко те условия, при которых она не эффективна.
                      Если для того же скрама написали бы, что это только и исключительно для быстрой web-разработки сравнительно простых (т.е. состоящих из слабосвязанных функциональных частей), но высокопроизводительных сайтов — ни у кого никаких претензий бы не было бы (и бабушка была бы дедушкой), но имеем то, что имеем.


                      Тут, конечно не надо вдаваться в крайности и вешать всех собак только на методологию или только на "эффективных манагеров" — они нашли друг друга.

                        0
                        Слепо пользоваться методиками — ненормально. Унитаз — это не методика. В данном контексте «слепое» пользование унитазом, это сесть на вновь привезенный из магазина, не подключенный к канализации, и справить нужду. Ведь все должно быть нормально, другие все предусмотрели?

                        Как по мне, надо разделять идею «гибкой разработки» (она очень здравая), сертифицированную скрам-индустрию прохиндеев и, отдельно, малокомпетентных водителей руками, верящих в карго-культ. Поменяй скрам на ERP — те же яйца, вид сбоку. Такие же автоматизаторы бардака. Потому как «вслепую», по методичкам.
                          +1
                          В данном контексте «слепое» пользование унитазом, это сесть на вновь привезенный из магазина, не подключенный к канализации, и справить нужду. Ведь все должно быть нормально, другие все предусмотрели?

                          А люди именно так и делают. Если унитаз стоит в кабинке/туалете очень сомневаюсь, что кто-то проверяет наличее и качество подключения к коммуникациям до того как.
                          Поэтому ответственный за наладку процесса (сознательный и опытный сантехник) обязательно поставит большую предупреждающую табличку — да ещё и обмотает унитаз скотчем и плёнкой во избежание. Это всё из практики нашей туалетной комнаты (и так и так было).


                          Люди вообще думают дай бог чтобы 5% всего времени бордствования (умные — 10%, гении — 20%). Всё остальное время — на автомате. Мем про 95% именно из этого следует. Это — нормально.


                          Поменяй скрам на ERP — те же яйца, вид сбоку. Такие же автоматизаторы бардака. Потому как «вслепую», по методичкам.

                          Потому что в методичках никто не написал, что это система вообще-то для ритейла. Не поставил большой предупреждающий знак и не обмотал плёнкой и скотчем (видимо ввиду отсутствия обратной связи в виде необходимости вычищать кучи образующихся нечистот :) ).

                      0
                      Ситуация зачастую гораздо проще: или бардак или скрам. При этом при наличии второго люди подсознательно стремятся его обардачить, чтобы было комфортнее. Отсюда и давление на скрам и его нерушимость.

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

                      Ну можно найти умного объясняющего, который придёт примеры из реальной жизни и покажет как скрам их решает. А затем задаст контр вопрос: «а как вы без скама это будете решать?»
                        +1
                        Ситуация зачастую гораздо проще: или бардак или скрам.

                        Сдаётся мне — это ложная дихотомия. Очень много задач можно решить простым календарным планированием с еженедельной (или двухнедельной) "нарезкой" задач и открывающими/итоговыми совещаниями. Это сложно назвать бардаком.


                        Ну можно найти умного объясняющего, который придёт примеры из реальной жизни и покажет как скрам их решает. А затем задаст контр вопрос, а как вы без скама это будете решать.

                        Очень хотелось бы найти и послушать. Но как-то не получается. Может Вы попробуете объяснить?

                          +1
                          Сдаётся мне — это ложная дихотомия

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

                          Очень много задач можно решить простым календарным планированием с еженедельной (или двухнедельной) «нарезкой» задач и открывающими/итоговыми совещаниями.

                          Конечно. Скрам включает в себя то, что вы описали, но также предлагает способы итерационного улучшения процессов.

                          Сразу скажу, что я не являюсь 100% поклонником скрама и его неотступного использования. Тем не менее его иногда проще внедрить и следовать, чем изобретать что-то своё.

                          Очень хотелось бы найти и послушать. Но как-то не получается. Может Вы попробуете объяснить?


                          Давайте попробую:
                          1. Planning poker. Несмотря на то, что описание задачи уже составлено и всем примерно понятно что делать, оценка может быть разной. И в результате обсуждения расхождений могут всплыть неявные моменты, неуказанные в описании задачи. В этот момент происходит уточнение и сроков и описания. При обычном планировании эта стадия пропускается.
                          2. Неадресность задачи. Благодаря всему процессу выше, появляется возможность (в идеале) любую задачу делать любым человеком в большей мере, чем при обычном планировании. Что снижает bus-factor.
                          3. А благодаря этому снижается эффект наличия 1-2 специалистов, которые кушают все самые интересные задачи, а остальные задачи выполняют менее квалифицированные коллеги, в результате чего первым людям существенно интереснее работать, чем вторым.
                          4. Процесс ретроспективы чётко описан и позволяет не забыть обсудить важные вещи, решить как их исправить, назначить ответственных и на следующем собрании проверить готовность.

                          Всё описанное выше применённое много раз позволяет научиться:
                          * хорошо бить задачи и иметь очень хорошее их описание
                          * оценивать влияние больничных и отпусков
                          * в целом хорошо определить успеем или не успеем к релизу и что успеем
                          * люди лучше высказывают о проблемах в процессе работы и лучше отслеживается их настроение

                          При простом планировании на 2 недели с концевыми собраниями у вас есть риски:
                          * погрязании части работников в трудной задаче, без ежедневных stand-up вы об этом не узнаете.
                          * более неравномерная квалификация команды и соц. проблемы описанные выше
                          * всем пофигу, что план всегда немного недоделан
                          * меньше вылазят неожиданные факторы при решении задачи

                          Как-то так.

                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                      Самое читаемое