Наш мир устроен очень странно. И чем дальше, тем становится страннее. И хрен поймешь, в чем дело.
Вот есть на свете инженеры и программисты. Иногда в одном лице. Люди, понимающие, что такое алгоритм. Более того – люди, создающие эти алгоритмы. Прекрасно знающие, что созданный алгоритм подходит для решения одной задачи, но не годится для другой. Понимающие, что если алгоритм чуть изменить, то он сможет решать смежные задачи. Не стесняющиеся выкинуть половину чужого алгоритма, чтобы он лучше решал текущую задачу.
Программисты создают решение под задачу, или под класс задач. В этом суть профессии. Там, где это возможно, используют готовые куски своего или чужого кода. И всё у всех хорошо.
Но, как только дело доходит до создания алгоритмов за пределами компьютера, программисты вдруг теряют голову. Я не говорю о рисовании схем алгоритмов на бумаге, как это было на экзамене в универе – тут любой из нас справится.
Я говорю о «внедрении методик», «работе по фреймворку», «обязательном использовании всех артефактов». О сектах, короче.
Немного идиотизма
Все знают, что такое условный оператор. Без него нет никакой жизни. Ни один приличный алгоритм работать не будет. Ни в компьютере, ни в жизни.
А теперь представьте: появился некий человек, допустим – Джон, и заметил, что в бейсике есть условный оператор. Поковырялся, разобрался, убедился – есть, работает, без него никак.
Допустим, Джон – туповат. Но решил покорить мир. Пошел продавать Бейсик. Не сам язык, а некую «крутейшую методику разработки программного обеспечения», центральным звеном которой является… А не скажет Джон, пока курс не пройдете.
Ладно, нашлись любители курсов, тем более, что цена не высока. Пришли, послушали, ахнули. Главным элементом крутейшей методики разработки программного обеспечения является Условный Оператор. Много послушали про условный оператор. Например, о том, как превратить его в оператор множественного выбора. Еще раз ахнули – какой могучий Условный Оператор.
Половину аудитории составляли программисты. Поржали, ушли домой. Еще четверть составляли менеджеры. Призадумались, позадавали вопросы, кто-то решил внедрить эту крутейшую методику у себя. Последнюю четверть составляли такие же, как Джон. Они уговорили парня на создание франшизы, Сообщества, Центра Сертификации и Университета Условного Оператора.
Программисты с курса вернулись на работу, уже не помня об Условном Операторе. Но через час пришли менеджеры и объявили, что теперь разработка ПО будет вестись по крутейшей методике. Да, которая про Условный Оператор. И вообще, писать лучше на бейсике.
Робкие, а то и не робкие возражения программистов были проигнорированы. Фразы типа «блин, это условный оператор, он везде есть» были восприняты как попытки повыпендриваться. Колесо закрутилось.
А Джон быстро понял, что мало одного Условного Оператора. Еще должен быть Цикл, Подпрограмма, Переменная, Массив и т.д. Надо бы как-то все это назвать… Одним словом… О, пусть это будут Артефакты! Ни больше, ни меньше!
Осталось главное: внести в методику пункт о том, что крутейшая методика разработки программного обеспечения – это целостное, холистическое знание. Значит, из него нельзя выкинуть ни одного куска. И в него нельзя ничего добавлять – работать перестанет. Как написано, так и делай.
Благодаря энтузиазму Джона и его друзей теперь весь мир пользуется не условным оператором, а Условным Оператором, не циклом, а Циклом, и т.д., по списку. Те, кто понимал идиотизм ситуации, давно ушли на пенсию или заткнулись. Те, кто пришел недавно, свято верят, что Условный Оператор – это часть крутейшей методики разработки программного обеспечения, созданной Джоном. А все остальные условные операторы – жалкое подобие, блеклая копия и выдранный из контекста кусок Знания.
Любой, кто посмеет подать голос в интернете (или, не дай-то Бог, внутри команды), будет подвергнут яростному осуждению и гневному минусованию – ишь ты, валенок, не видишь преимуществ Условного Оператора! А если несчастный попросит объяснить, в чем смысл и отличие от условного оператора в C++, javascript или даже 1С, получит в ответ «это невозможно объяснить», «тебе не понять», или «иди читай гайд».
Инструменты и алгоритмы
Все понимают, что такое условный оператор, и как его использовать в алгоритмах. Точно так же все понимают, что такое, например, стикер с записанной задачей. Стикеры появились до скрама, и живут вне его. Посмотрите на компьютер бухгалтера, снабженца или продавца. Они еще не изжили привычку вешать на монитор кучу стикеров со срочными задачами. На одном из стикеров будет написан пароль.
Любая методика легко разбирается на инструменты, принципы и связи. Так же, как любой алгоритм разбирается на фигурки разных форм и назначения – начало и конец алгоритма, действие, условие, подпрограмма.
Любая методика имеет область применения. Не всё там абсолютно – есть более подходящая среда, есть – менее. Так же, как и у алгоритмов.
В любую методику можно вносить изменения. Выкидывать куски, добавлять новые, модифицировать конкретные инструменты. Так же, как и алгоритмы.
Любые методики можно миксовать, целиком или по кускам. Взять половину от одной, четверть от другой, еще четверть – выдумать самостоятельно. Когда вы создаете приложение или сервис, для вас это очевидно.
Правда, остается вопрос – будет ли методика методикой, если ее поменять?
Вот как отвечает на этот вопрос, например, широко известный Scrum Guide:
«Роли, артефакты, правила и события Скрама не подлежат изменению. Хотя использование отдельных элементов данного фреймворка допустимо, но полученный результат не может называться Скрамом. Скрам существует только в качестве цельного фреймворка, но он может вмещать в себя другие техники, методологии и практики.»
Немного напоминает Джона и его Условный Оператор, не правда ли? Вроде как, меняйте, если хотите, только это будет не скрам. И каков будет результат – хрен его знает. На всякий случай отметили, что внутрь можно попробовать чего-то засунуть. Но костяк должен оставаться. Иначе… Даже страшно представить.
Так ли уж страшно? Что будет, если часть артефактов выкинуть или заменить? И вообще, какой в них смысл? Откуда они взялись? Почему считается, что они работают только в таком сочетании, как решили авторы?
Попробуем разобраться по частям.
Спринт и Бэклог Спринта
Отличный инструмент, кстати. Изобретен, наверное, лет тысячу назад. Только назывался всегда по-разному, но самое, наверное, распространенное – «План». А по-человечески – «сделать определенный объем работы за определенный промежуток времени».
Мне, как 1Снику, он больше известен, как объемно-календарное планирование (ОКП). Широко применяется при планировании производства и продаж. Например, план продаж менеджера, равный 1 млн. рублей в месяц – это бэклог и спринт. Иногда достаточно цифры, иногда бывает разбивка по группам продукции, или ограничения по рынку сбыта, или даже есть конкретный перечень номенклатуры, если того требует стратегия компании.
В производстве еще проще. Втулок – 1000 шт, валов – 2000 шт, роторов – 500 шт. Это, допустим, недельный план. Он же – бэклог недельного спринта производственного участка. Правда, рабочим можно не объяснять, что это – не план, а спринт.
Инструмент хорош в сравнении с распространенным управлением по срокам, когда пул задач программистов оценивается по трудозатратам, упорядочивается по какому-либо критерию, и у каждой задачи рождается срок выполнения. В производстве это называется посменным, или цеховым планированием, из которого потом создаются задания на производство, содержащие перечень деталей и полуфабрикатов, тех.операций, материалов, входов и выходов (где что взять и куда передать результат).
Для программистов цеховое планирование работает плохо, тут и обсуждать нечего. Время обработки детали на конкретной модели станка известно давно и достаточно точно. Периодичность обслуживания – тоже. Достаточность материалов оценена. Бери и делай. Вариации, мешающие выполнению плана, в серийном производстве обычно не оказывают значительного влияния. А если оказывают – есть прекрасные методы для их анализа и устранения.
Вариации программиста намного сильнее. Он ведь – не станок, как бы того не хотелось некоторым менеджерам, пришедшим в ИТ из продаж или производства. Поэтому цеховое планирование (задача + срок) для программиста не годятся. Вот и придумали толковые люди – надо подняться на уровень выше, не расписывать исполнение по минутам, а дать объем на период. Только название другое придумали – спринт и бэклог.
Наполнение объемно-календарного плана производства строится по принципам, схожим с формированием бэклога спринта. Даже есть такое понятие – «набрать план». Есть потребности того же отдела продаж (= большой бэклог), есть пропускная способность производства (= возможности команды в цифрах), плюс есть понятные критерии выбора – сумма продаж, рентабельность каждой позиции, параметры заказчика (например, условия оплаты). Набрал план производства – и сразу видишь, какой примерный финансовый результат получишь. Это не эфемерный «релиз».
Есть ли недостатки у этого инструмента? Разумеется, как и у любого другого.
Если разобраться, бэклог спринта – то же цеховое планирование, только без выстроенной последовательности решения задач. Поэтому у всех задач один срок выполнения – конец спринта. Раз срок у задач один, то появляется неприятный эффект – в начале спринта активность может быть значительно ниже, чем в его конце.
Так работает любая человеческая психология. Всегда хочется поваландаться в начале периода исполнения, будь то одна задача, или бэклог. Отдохнуть от прошлого периода, особенно – от его финальной части, когда пришлось выдать «на гора» колоссальный результат. Есть, конечно, люди стабильные и ритмичные, работающие всю неделю на одной скорости, но большинство начинает «нормально работать» где-то в среду.
Можно ли обойтись без спринта и его бэклога? Легко.
Например, применив инструмент «как можно быстрее». Вообще, это не прапорская замашка, а вполне себе нормальная стратегия того же цехового планирования (As Soon As Possible, ASAP). Означает, что выпуски будут «прилипать» к началу отрезка времени, т.е. к понедельнику, а не к пятнице, как при стратегии планирования «точно к сроку» (As Last As Possible, ALAP).
Планирование, как таковое, в этом случае не нужно. Есть бэклог продукта, есть приоритеты, есть правило «как можно быстрее». Берешь первую и делаешь. Закончил – берешь вторую. И так – от забора до обеда. Спринт, а точнее – его сущность, т.е. отрезок времени, можно оставить для понимания и анализа производительности (неделя к неделе, месяц к месяцу, и т.д.).
Есть ли недостатки у стратегии «как можно быстрее»? Конечно, миллион. Во-первых, человек может быстро устать. Во-вторых, он будет чувствовать себя станком. В-третьих, он, скорее всего, сбежит – туда, где используются обычные спринты с бэклогом. Или просто ставят задачи и ждут результата. В общем, где поспокойнее. Но практика показывает, что и «как можно быстрее» вполне можно жить годами, если здраво понимать, что это стратегия планирования, а не потогонка.
Можно ли выкинуть спринт и его бэклог? Нет. Не потому, что это – уникальные придумки того же скрама, а потому, что это естественный способ планирования, которым, в той или иной форме, пользуются все. Вариаций много, принцип один – нужно сделать определенный объем работы за определенный промежуток времени.
Является ли такой инструмент, как спринт, уникальным и ключевым элементом какой-либо методики? Нет. Это всё равно, что утверждать, будто набор кода на клавиатуре – уникальная придумка какой-то методики. Почти все тексты набираются на клавиатуре.
Скрам-доска
Формально, доска не является артефактом или правилом, но, думаю, про нее тоже стоит поговорить, потому что есть среди людей довольно явный паттерн: скрам – это доска со стикерами.
Тут, в общем-то, вы сами всё понимаете. Доска со стикерами, на которых записаны задачи, не является чем-то уникальным. Это, грубо говоря, кроссплатформенный инструмент. У меня жена на холодильник иногда стикеры лепит со списками дел, хотя ничего не знает ни про какой скрам.
Хорош ли этот инструмент? Смотря с чем сравнивать. Да, пожалуй, хорош.
Например, он позволяет быстро оценить, окинуть взглядом пул задач. В компьютере, или любом другом электронном устройстве, задачи нужно листать – в один экран всё, обычно, не помещается. Следовательно, в один взгляд – тоже.
Еще важный плюс – общая доступность для команды. В любой момент можно подойти и посмотреть, не надо заходить в какую-то систему, искать, делать выборку и т.д.
Многим нравится невиртуальность доски. В компьютере ведь все – виртуальное, руками не потрогаешь. А тут – пожалуйста, хоть облизывай. Некоторые, в этой связи, любят пробковые доски. Разница – примерно как между бумажными и электронными книгами.
Конкретно для скрам-доски можно отметить такое преимущество, как разделенность на две части – в работе и выполнено. Бытовое обращение со стикерами предполагает выкидывание тех, что уже завершены – не очень хорошо, т.к. прогресс виден хуже.
Есть ли недостатки у скрам-доски? Конечно. Как и у любой доски.
Начать с бытовых – сквозняки, некачественные стикеры, плохой почерк, саботаж. В результате – потерянные задачи и неразбериха в управлении.
По доске не очень виден прогресс. В целом за спринт – да. За сегодня, вчера – нет. Отсюда необходимость в ежедневных обсуждениях.
Конкретно по скрам-доске не видны статусы задач, если жизнь сложнее, чем «запланировано» — «сделано». Предпочтительнее выглядит канбан-доска.
Доска не позволяет нормально работать, если команда территориально распределена. Поэтому появляются электронные доски.
Электронная доска, как мне кажется, верный признак сектанства. Она потеряла все преимущества обычной, но, по какой-то неведомой причине, ей продолжают пользоваться. Вероятно, просто потому, что это – доска. Часть Методики.
В общем, инструмент, как инструмент. В определенных ситуациях – хорош. В некоторых – ужасен.
Будет ли работать скрам без доски? Легко. И доказано практикой. И вроде как, раз доска не является обязательным артефактом, можно будет продолжать называть скрам – скрамом.
Скрам-мастер
Кто такая эта чудо-роль? На что похожа?
Вариантов много. Например, скрам-мастер похож на тренера в спорте. Есть, допустим, футбольный клуб. Владелец продуктам там – менеджер, который определяет цели команды. Тренер – тот, кто помогает команде этих целей достигать.
В обычной, производственной среде, никаких тренеров нет – если бы так работал футбольный клуб, то начальник просто приходил бы в раздевалку перед матчем и говорил: «идите и выигрывайте». А когда проиграют, устраивал бы разнос. Кого-то выгонял, кому-то угрожал и т.д. Как на заводе.
А тренер, как и скрам-мастер, служит провайдером между командой и менеджером. Власти у тренера, конечно, побольше – он не лидер-слуга. Но и результат от него требуется более быстрый и понятный – никто не будет ждать, пока он там кого-то фасилитирует. Тренер, как и скрам-мастер, понимает, как должна функционировать команда, т.е. он те просто задачи ставит, а объясняет, как их надо решать. Налаживает связи, мотивирует, создает и поддерживает атмосферу и т.д.
Другая аналогия – командир взвода, спецназа какого-нибудь. Это – играющий тренер. На задания ходит вместе с подчиненными, точно так же решает боевые задачи. В свободное время – руководит подготовкой и повышением мастерства, освоением новой техники, физ.подготовкой. Разумеется, постоянно работает с командой в плане психологии – мотивирует, поддерживает, помогает. Своеобразными методами, конечно, иногда, но цель-то одна – максимальная боеспособность взвода.
Скрам-мастер, по сравнению с этими ребятами, халявщик. За результат не особо отвечает. Отсутствие формальной власти, вроде бы, воспринимается как преимущество – он же лидер-слуга, но на деле может перерасти в безответственность. Можно ведь до бесконечности фасилитировать, не оказывая никакого влияния на результат? А когда выгонят – искать другую команду, чтобы там фасилитировать.
Можно ли изменить или убрать роль скрам-мастера? Конечно. Например, объединить эту роль с владельцем продукта. Знаю, в Методике написано, что так лучше не делать – это помешает мастеру фасилитировать. Но, зато, добавит понятных целей и ответственности. Когда цель понятна и измерима, тогда и фасилитация превращается из необязательной, непонятной хрени во вполне конкретную, осязаемую обязанность, прямо влияющую на результат. Как у тренера или комвзвода.
Правда, тогда смысл называть его скрам-мастером потеряется. Это будет, наверное, тимлид – не забываем, что «лид» — это лидер. А лидер – это не только флаг в руках, но и работа с мотивацией, целями, умение увлечь за собой, привнесение новых методов работы, натаскивание компетенций и т.д. Драйвер команды, короче. И в смысле внутреннего развития, и в смысле достижения результата.
Если в скраме заменить мастера на тимлида, что произойдет? Скрамом это уже нельзя будет называть – одна из ключевых ролей выкинута. А на результате как скажется? А если вообще без скрам-мастера? Если его функции размазать по команде, как это рекомендовал сделать Белбин? Один фасилитирует, другой мотивирует, третий следит за исполнением правил. Вполне себе можно так жить.
Итого
Ну всё, дальше принцип понятен. Скрам, как и любая другая методика – это алгоритм, сотканный из компонентов, или инструментов. Кто его соткал? Ну, допустим, Джефф Сазерленд и Кен Швабер.
Представьте, что два парня, Джефф и Кен, создали некий компонент, приносящий неплохую пользу в разработке веб-приложений. Вы его нарыли в гитхабе, установили, попробовали – ого, прикольно! Работает! И правда, лучше стало!
А потом, в какой-то момент, вас в этом компоненте стало что-то раздражать. Например, вызов его методов кажется недостаточно полиморфным. Вы заходите в исходный код и обнаруживаете…
Чего вы там можете обнаружить? Да всё, что угодно. Например, заимствования, которые вам не понравятся. Или заимствованные компоненты будут правильными, но криво использованы. Или прямо указана конкретная версия хорошего компонента, а он хорошо развивается и давно стал в разы круче, но разработчики не хотят адаптировать вышестоящий компонент. Или обнаруживаете в алгоритме кусок приличного размера, неплохо так отжирающий ресурсы, но не несущий конкретно для вашего проекта никакой пользы.
Что будете делать? Каждый ответит что-то свое, конечно. Кто-то даже внутрь не полезет. Кто-то сделает форк и поправит то, что не нравится. Обретет, конечно, некоторые проблемы с обновлением. Хотя, не факт – такие штуки, как скрам, не меняются годами. Кто-то напишет разработчикам. Чего они ответят – не знаю.
Кто-то же просто возьмет исходные компоненты, и пересоберет их по-своему – так, как надо в конкретном проекте или продукте.
Точно так же можно поступать с любыми методиками. Хотел написать «можно и нужно», но не стал навязывать свое мнение – каждый ведь сам решает.
Закончить хочу цитатой Голдратта. Это, возможно, единственный из светил, разработавших какие-то методики, честно говоривший о необходимости их изменения, адаптации, компоновки и, главное, понимания принципов функционирования.
Существует разница между практическими методами и фундаментальными концепциями, на которых основаны эти методы. Концепции являются общими, практические методы – это адаптация концепций к конкретной среде. Как мы уже видели, подобная адаптация не является простой, и делает необходимой разработку определенных элементов решения. Что мы должны помнить – что подобное решение основано на исходных посылках (иногда — скрытых) о конкретной среде. Мы не должны ожидать, что это решение будет работать в среде, для которой эти исходные посылки не являются верными. Мы можем сэкономить множество усилий и избежать разочарования, если скрупулезно сформулируем эти исходные посылки.
У меня сложилось впечатление, что вы по ходу рассуждений куда-то уплыли от ответа на вопрос.
(1) странно, я думал всё очевидно. Разобрать «сектантскую» методику на понятные куски и понять, что в конкретной «сборке» ничего особого нет.
(2) забыли сказать про магию англоязычных наименований
процитирую себя же
Agile software development — звучит красиво ,
Проворная разработка программ — ну , не очень …
если выдумать новую методику , например когда нужно кодить стоя на голове , ее
лучше назвать Upside down software development
Сокровенная ересь!
Е́ресь — сознательное отклонение от считающегося кем-либо верным религиозного учения,
Мне тоже очень нравится Условный Оператор.
守破離 — Cю Ха Ри.
Для того чтобы перейти на последний этап мастерства необходимо пройти сначала первые два. В последнее же время очень распространена мысль, что раз конечным этапом всё равно является Ри, то и первые два этапа не нужны. Следствием часто является дилетантский подход и отрицание правил. Наш любимый лозунг — правила существуют чтобы их нарушать.
Нет ничего нового ни во фреймворке скрам ни в регулярном менеджменте ни даже в ТОС. Ни в том числе в этих публикациях. Но это качественные систематизации, выполненные опытными людьми, наступившими на кучу граблей прежде чем прийти к методикам и фреймворкам. Конечно можно сделать лучше. Но путь отрицания первых двух стадий обучения ведет к верхоглядству и отсутствию дисциплины. К подмене понятий, карго-культу и затем разочарованию в технологии.
Новичок приходящий в школу боевых искусств стремится скорее научиться эффективно морду бить. А его дыхательным практикам учат, выполнению простых движений и вестибулярный аппарат тренируют. Негодяи, отклоняют от быстрого достижения конечной цели )) Интересно, почему? Наверное чтобы денег содрать побольше. Иначе бы сразу показали как «ускориться в 10 раз» ))
Так и здесь. Недавно была публикация по мотивам книги «Чистый код». Заявления вроде «не надо новичков этому учить, им главное чтобы вообще работало» и «ничего нового, каждый сам мастак, не надо это слушать» тоже удивляли. То есть сначала пускай выработаются плохие привычки, а потом наступлением на те же грабли, на которые наступали сотни других людей человек выстрадает свой стиль разработки. При этом попортив информационные системы на нескольких предприятиях и усложнив жизнь коллегам и последователям в части поддержки кода и систем.
Интересно, что за пределами кустарщины мира 1С всё выглядит иначе, и даже в качественные IDE проверка стилистики встроена и начинающие разработчики благодарны за такие подсказки. Это их шаг на пути к профессионализму и общению с коллегами на одном языке.
Советы вроде «это всё придумано 2000 лет назад» не позволяют использовать технологии. А ведь именно соблюдение и тиражирование технологий всегда было слабым местом нашей культуры. Быть кулибиными и придумывать гениальные гениальности без проблем, отрицать правила — да. А дисциплинировано соблюдать технологию и затем уже на её основе строить свою и, что самое главное, затем тиражировать, масштабировать соблюдение правил — вот здесь возникают проблемы. Речь конечно сейчас о технических направлениях и практиках.
Комментарий не только к этой публикации. Все последние публикации автора на эту тему вот такие мысли вызывают.
В программировании сейчас Второе Вавилонское Столпотворение. И эта эпоха давно бы закончилась, если бы за изобретение новых слов и принципов грамматики и синтаксиса не платили денег. Например, в России за это платят меньше. У нас больше ценится общение с носителями языка.
Самой большой проблемой в начале карьеры является понимаете двух вещей — чего от тебя хотят и что ты можешь на самом деле?
Поскольку теория ограничений Голдратта применяется в первую очередь к человеку уже на этапе описания вакансии.
(7) Разработка за пределами 1С как раз давно впитала в себя инкрементальную разработку и скрам и перешла к следующему техническому этапу — непрерывной поставе, CI/CD, автоматической проверке качества, контейнеризации, масшабированию организационных подходов по LeSS, SAFe.
А в мире 1С в это время до сих пор со скрамом на команду в 9 человек борятся.
Считают, что этот фреймворк, фактически появившийся десятки лет назад — буржуйская новинка.
И убеждают себя что надо изобрести свой свод законов, потому что «законы Российской Федерации» какие-то не уникальные и в них нет ничего нового ))
(8) но они же не тратят ресурсы на преодоление языкового барьера?
(9) Путь изоляции и изобретения велосипедов не самый лучший. Но возможно действительно именно языковой барьер является причиной страхов и отрицания технологий. Были такие мысли тоже.
Довольно уютно кодировать на 1С печатные формы и писать очередную систему учета задач, которая даже никогда не будет с системами учета версий интегрироваться. Зато своё и без английского )) Хотя сочетая такой мощный инструмент для решения бизнес-задач как 1С и технологии специально предназначенные для разработки, можно лучшего качества достичь.
(6) вы же и первые публикации автора читали. Значит, помните, что там были и Сю, и Ха, и Ри.
Но публикация вообще не об этом.
(11) Сначала были. Но потом началось….
Показалось, что первые этапы были Вами пройдены и пришло понимание, что пора переходить на следующий этап.
Но вместе с этим в публикациях появился призыв к тем, кто только встал на путь работы по процессам и обучения, сразу прыгнуть на этап Ри, минуя предыдущие.
И конечно мысль «они там в своих буржуйских странах ничего нового не придумали» нашла широкую поддержку. Здесь опять фреймворки и технологии к сектам приравниваются. Может быть поэтому наши ё-мобили и ё-фоны всё ещё не вызывают желания стоять за ними в очередях? Надо технологии подтягивать.
А для этого нужно немного умения работать по ним, а не доказывать их несостоятельность только потому, что они собраны из ранее известных компонент.
Мир разработки, если смотреть глобально, давно впитал в себя и древний как остатки мамонтов скрам и прочие техники командной разработки. Сейчас идёт следующий этап, уже более технологичный. А мы боимся в секту попасть, хотя если посмотреть на проходящий мимо прогресс, то таким образом себя в неё и загоняем.
(10) качество жизни вообще очень обширное понятие.
И да, разница в качестве жизни существует и на это могут быть форс-мажорные обстоятельства
(12) мне кажется, у вас слишком идеализированное представление о мире разработки вне 1С. Наверняка же читали, что об этом пишут тру программисты?
Скрам они как впитали, так и испарили, через минуту. У них ровно такой же скрам, как в партнере 1С их пяти человек в маленьком городе Фершампенуаз на юге Челябинской области.
И так у всех. Никто не видит в скраме то, что в него заложено, в чем его суть и смысл. Никому скрам не приносит тех результатов, ради которых он создан. И, как следствие, никто не хочет понять, почему скрам работает. Ну и, естественно, не остается энтузиастов, готовых разобрать скрам и собрать заново.
Вот вам, Владимир, какой результат принес скрам?
Умение программиста преподать себя много значит, но может быть и ошибка
(14)
Конечно же ускорение в 4 раза. А потом и ускорение в 10 раз!На самом деле нет.Снижение количества косяков.
Снижение рисков сделать не то, что нужно.
Понимание необходимых компетенций до старта работы по задачам, а не после.
Лучшая оценка сроков выполнения задач.
Повышение личной мотивации, в том числе для работы по задачам, которые в иных системах сильнее вызывают демотивацию.
Фокусировка на цели и её достижение в коротком интервале планирования.
Много чего ещё.
Можно ли достигать того же самого без применения распространенных систем и изменив терминологию? Конечно можно. Но человек такое ленивое существо, что вне системы всегда находится куча причин, чтобы нарушить правила и не завершить работу или завершить её так, чтобы «почти работало». Или завершить её не выдержав установленные критерии качества.
Изобрести свою систему? Попахивает эгоизмом и желанием подогнать под себя все процессы. Всё равно что изобрести свои стандарты разработки конфигураций 1С при наличии общепринятых и понятных правил. Возникает фгагментация. Сначала команда заявляет «у нас своя система». Потом каждый внутри команды «у меня своя система». Ведь каждый из нас очень умный и может придумать уникальную уникальность в для организации процесса разработки.
А причиной всего, что вы написали является лень, а не технология. Работать соблюдая технологию сложнее, чем работать на тяп-ляп. И менее выгодно для почти для каждого индивидуума в отдельности, включая наделенных полномочиями. А ещё может бить по самолюбию. Так появляется нежелание использовать «буржуйскую» терминологию и попытки заменить её своей. Мы же сами с усами, если Швабер смог, то чем мы хуже? )) В итоге отказ от технологии зачастую выгоден и исполнителям и руководству.
Можно придумать другую систему и назвать её системой «Вани Пупкина» или менее персонально «Айсберг лучшего графомана» )) Но вот зачем? Если не смогли придерживаться распространенной технологии, то и с системой имени себя любимого то же самое будет.
Хотя не исключаю, что из города Фершампенуаз всё видится по-другому )))
Ок, давайте вспомним как мы учимся читать. Сначала по слогам (ма-ма мы-ла ра-му). Затем читается целиком слово, даже путаница букв внутри слова особо не мешает, на это есть масса примеров в интернете.
Из лайфхаков по конспектрованию мы помним, что тире внутри слов читаются тяжело, быстро записывается стенограмма, но требует расшифровки и читается медленно.
Окончания типичные и отдельные часто используемые слова можно заменить символами, как в математике или стенограммах.
Теперь возьмём среднестатистического программиста, который для быстрого понимания кода должен фотографически помнить и написание Артефактов и всех используемых переменных, иначе разбор кода превращается в расшифровку древнешумерских глиняных табличек.
Добавим сюда грамматику в наименовании переменных, и мы уже вчитываемся в каждую букву модуля, чтобы не позволить себя обмануть тем, что написано мелким шрифтом или плохим почерком или не в том регистре или не в том падеже или не в том склонении.
Практика приводит к тому, что программист, освоивший типовые конфигурации, может работать один, а при работе в команде требуется единство стиля, а оно как правило достигается общим файлом шаблонов.
Что вы думаете про английский вариант кода?
Дочитал до плана и скрама со спринтом и бэклогом. И сразу понял, что аффтор толкает здравую мысль, пропущенную через свою больную голову и сам же начинает доказывать, что спринт — штука отдельно работающая плохо.
Если вспомнить про канбан, который придумали стажеры в тойоте, то мысль тут как раз в том что план адаптивен. Фактически это макдональдс, в котором есть ячейки для вмего фастфуда и нет планирования, т.к. никогда не знаешь, чего бол ше скушают голодные 1Снеги — гамбургеров, чизбургеров или еще какой хрени. И вот пустеющая ячейка — это план. Если просто поставить задачу сделать сто всего, то может так оказаться, что одного съели сто, а другого только пять, поэтому подход с планом не работает.
Аффтор, иди и еще раз подумаю про секты и отличия сект от технологий. Вот ты уже, полагаю, знаешь, что есть такие люди — коучи. И среди них есть технологи, а есть вольные стрелки, которые чтото там миксуют и придумывают. Вот поверь, что технолог вытащит тебя к свету за пять занятий, а вольный священномученик со своей методологией будет жать из тебя бабло пока может.
(6)
Тоже показалось, что экзистенциальный кризис автора вступил в фазу отрицания всего. С другой стороны, совсем без отрицания тоже нельзя. Сомнение во всем, определяемое величайшими логиками как критическое мышление, — это единственный путь прогресса. Но пока не умеешь — действительно лучше повторять, используя те самые best practice.
(19) Вот из-за таких бездумных «повторителей» из числа эффективных менеджеров у скрама такая подмоченная репутация…
(20)
Так чтобы повторять, нужно разобраться в том, что повторять. А пока не понимаешь, то и не повторяешь вовсе, а пытаешься повторять. Но лучше пытаться повторять, чем изобретать велосипед. Рано или поздно разберешься. А вот уже когда «пробудился»- вот тогда можно и свои мысли вкладывать, улучшающие процесс.
(21) Разобраться — это не про «эффективных менеджеров». Ну и, опять же, в скраме ничего сложного/необычного нет, только вот не всегда и не везде его пихать можно/нужно.
(22)
Где не нужно? Где не можно? Давайте разберем примерчик.
(23) Не нужно для слаженной команды разработчиков — они и так нормально работают. Нельзя в непродуктовой разработке :))
Много букв))
(24) а что такое «слаженная команда»? На мой взгляд — это любая проектная команда, которая уже долго работает вместе. По опыту спринт и покер планирования даже для такой команды дают увеличение производительности труда. Часто в этой самой «слаженной команде» уже так или иначе подобный подход используется, но спринт позволяет видеть изменения в реальном времени.
Непродуктовая команда — это что? Яндекс молчит. Это саппорт? Администраторы? У них есть ITIL и инциденты, которыми можно также проактивно управлять, а не только реактивно, снижая вероятность тех или иных проблем. И там скрам тоже вполне может повысить скорость и качество работы, но если админ один — да, тут работать не будет )))
(26) А вы вот точно уверены, что скрам — это про повышение производительности? Точно-точно?
(27) все методологии управления проектами нужны для повышения ROI. И это произаодительность труда, т.е. снижение стоимости создания продукта.
(28) Ну есть мнение, что скрам про быстрый запуск, и последующую шлифовку продукта. А видимость роста производительности лишь видимость…
(29) Тот же Макконнелл пишет, что парное программирован е и ревью позволяют выявлять до 70% ошибок при кодировании, в то время как стандартное тестирование только 30% при куда больших трудозатратах (на примере Боинга была показана цифра — в 8 раз). Так что тут все зависит от целеполагания и погимания процессов разработки ПО. Дай СКРАМ обезьяне — и будет как с очками… мартышка к старости слаба глазами стала, но от людей она слыхала…
(18) пояснили бы мысль-то. Что у меня за болезнь. И чем бэклог+спринт отличаются от ОКП.
(16) погодите, а где я говорил, что не работал по технологии скрама? Или что-то с ней не получилось?
(30) Ну да, парное программирование, коде ревью… Но скрам то тут при чём?
(32) О, тогда какой продукт был создан тобой по скрам?
(34) нашел время спросить, это было года 3-4 назад. Это были скорее проекты, чем продукты. Хотя граница размыта. Всё по внутренней автоматизации.
Из того, что помню:
1. Настоящий ФИФО в РАУЗ со структурой затрат;
2. Организация наполнения консигнационного склада внедрением ТОС и потоков (консалтинговый проект, автоматизации мало — существующими инструментами сделали);
3. Стратегический монитор с внедрением — сбор показателей с разных источников в один большой светофор с иерархией (автоматизация + методика);
4. Какой-то небольшой проектик были по устранению конфликтов в КД между разными службами и заказчиками;
5. Заявок (разовых задач по автоматизации) сделали в 2 раза больше на скраме (но тут без проекта, просто поток);
6. Внедрение по скраму скрама в другом отделе.
Больше не помню. Точнее, проекты или продукты, как сущности, не могу выделить. Мы работали с потоком задач, в котором были и проектные, и обычные. Только для важных проектов компоновали бэклог для ускорения релизов.
(34) но, вообще, вопрос у тебя странный. Создать продукт по скраму можно за один день, это очень простая методика.
Я вот в выходные шкаф сам сделал, тоже по скраму, из другого шкафа.
Кажется, понял. Надо было сразу написать: статья для тех, кто освоил скрам или любую другую методику, но хочет двигаться дальше. Только не брать новую методику, а взять лучшее из существующих, причем только то, что подходит для конкретной среды, и скомпоновать.
Аналогия. Есть типовая УПП. Хорошая, чудесная, замечательная конфигурация. Можно оставить на замке и работать.
А можно улучшить — небольшими усилиями подстроить под себя, получив реальные преимущества.
А можно не трогать УПП, а взять другую типовую. ERP, например. И гордиться всю жизнь тем, что «я не мудак какой-то, который всё отрицает, у меня и телефон франча есть, там быстро объяснят, что надо на типовом работать».
(35) И что, реально был продакт-овнер член команды, и команда кросс-функциональная, и стендапы ежедневные? Не верю :)))
(37) Ну наконец то. Я давно говорю, что много непонимания у читателей от отсутствия в твоих статьях границ и условий применимости…
(38) и скрам-мастер, и доска, и стикеры, и ретроспективы, и мат, и всё, что положено при русском скраме.
А в чем сложность-то?
(39) так надо последовательно перечитывать все статьи от первой до последней. Из контекста выхватывать бессмысленно.
Вот есть статья про бизнес-программирование, которая с выступления 2016 года. Там скрам вскользь упомянут. И про ускорение вдвое сказано.
Потом статья, через год, с выступления 2017 года. Там уже подробно рассказано и про скрам, и про то, почему мы его выкинули, и какие внесли изменения, и зачем, и что в итоге получилось.
А в 2019 году, естественно, я этого не пересказываю. Сейчас — совсем другие задачи.
Например, повышение прибыли и выручки. Но — на основе всего этого опыта.
Если кто-то умеет увеличивать выручку, например, франча, используя чистый скрам — ради Бога. Моя практика показывает, что это нереально, надо модифицировать.
А скоро поздно будет. Один франч уже выручку увеличил. Сейчас второй на очереди. А парни пусть пока раздают телефоны коучей и рассказывают, как помогает скрам повысить качество, как его на западе используют и т.д. Каждому своё.
Ты ведь не подумал, что статья про ту девушку — выдумка?
(39) да, и еще. Скоро выйдет последняя статья на тему ускорения, скрама и тому подобного. В смысле последняя, где я делюсь опытом. Слишком быстро и высоко возрастает ценность этого знания в последние месяцы. Ну и, очевидно, что это никому не интересно — причем, на любой площадке.
Так что, всем радоваться. Я тоже пошел, пиво греется.
(40) Ну смешно это как-то в контексте 1С :))
(42) А вот это интересно — почему не интересно :)) Есть предположения?
(44) публика не та.
(33) вот, уже начали задавать правильные вопросы. Вопрошание — это путь к познанию истины, хотя где мы, а где истина?)))
(45) А ты перестаёшь быть идеалистом :))
(46) Так истина в том, что скрам и аджайл немного разные вещи :))
Нужно попросить помощи у друзей.
(31) помнится, в одном из писем автор жаловался на то, что здоровье ни к черту. Или я не правильно понял?
Т.е. с остальным автор согласен?
А по поводу отличия ОКП от иных каких технологий в том, что для первого проект должен быть достаточно глубоко проработан (НИОКР), создано четкое ТЗ, в нем должны быть определены вехи, чекпоинты, исчислимые показатели и их уровень для перехода к следующему этапу. Макдональдс на такой методологии бы не смог работать — это характерно для блинных и картошечных, очереди в которые лично я не наблюдаю.
Особенность современного создания стоимости в том, что когда ты начинаешь чем-либо заниматься, ты не можешь гарантировать то, что дело выгорит. Как автору должно быть известно, в 20-х годах 20-го же века некий товарищъ решил, что раз из тысячи идей (даже почти двух тысяч) начинает активно создавать стоимость только одна, то не плохо было бы напилить тысяч десять вариантов и потом их проработать. Т.е. взять количественно, не выкидывая даже самые бредовые. Так появился мозговой штурм. Потом Альцшуллер предложыл технологически подойти к генерации идей, отсеивая бред сразу — он просто не сможет в создаваемых условиях генерироваться массивно — так появилась ТРИЗ.
SCRUM — это, в переводе, собственно, «схватка». Т.е. некая такая борьба и преодоление трудностей изменения для повышения эффекта, т.е. увеличения создаваемой стоимости. Все методологии на это завязаны, т.к. их основная задача — принести пользу. Задача автора принести пользу себе через увеличение дохода компании, в которой он на каких-то условиях работает. Вряд ли у автора есть план. И сам же автор жаловался, что если бы его кто попросил писать эти статьи, то выходило бы куда хуже. Так вот и SCRUM — это такая вот схватка с действительностью при нечетком плане, непонятном будущем, основанная на зарисовках чего-либо и вывешивании этого зарисованного на видном месте, чтобы бросалось в глаза и было о чем подумать и чем повосхищаться может быть . И вот там есть ритуалы, артефакты, принципы и ценности, и даже политики. Все это отличает формализованный подход того самого ОКП от свободного и даже халократичного подхода скрама, когда войско разработчиков бросается на штурм проекта, а не лениво насиживает жопу на мягком кресле руководителя или на кресле админа с иголками в виде инцидентов, на которые нужно реагировать (поэтому админы — тощие, ибо суета).
(48) ну это как рыба и селедка.
(50) мы про разное ОКП, похоже. Я про «сделать вот эти задачи за неделю». Как план производства в УПП — номенклатура, количество, период.
Бэклог спринта — то же самое. Никто не мешает создавать, например, план производства на неделю (если технология позволяет быстро перестроиться).
Глубокая проработка — это уже про водопад. Ну и она не связана с методом выполнения проекта.
В скраме тоже есть место глубокой проработке до начала реализации — в книге Сазерленд об этом писал.
Это вещи, вам очевидные, раз вы starik. А вот мне, молодому, не понятно, зачем вы пишете пространные комменты — вы вроде не тролль.
(52)
5. отвлекаюсь от сложной работы, чтобы с новыми силами преодолевать сложность.
1. Как я понял, здоровье Ваше лучше не стало. Жаль. Надеюсь, активный образ жизни однажды возьмет верх над пассивным.
3. Ну если говорить о коротком плане на недельку, то этот план как-то должен появиться. И как Вы его делаете? Неужели через покер планирования?
2. Место глубокой проработки есть везде, а гибкость подхода заключается в том, что изменения направлены на постоянное улучшение, а не локальные хотелки из того, как кто-то сто лет назад придумал — время прошло, старые идеи могут не работать (хотя я сам писал о том, что ничего нового не придумали, но это в плане подходов — просто синтез через тезис и антитезис, то самое единство с этой самой борьбой противоположностей, как средство синтеза нового)..
4. Особенности современного создания стоимости в том, что ты вынужден стрелять в множество разных мишеней, которые стали весьма динамичными. Сейчас ведь стартапы покупают часто не из-за самих стартапов, а из-за команды — дефицит кадровый. Кто бы во времена расцвета Йаху, который не купил Гугл, об этом думал? А ведь двадцать лет всего прошло. Все меняется, поэтому важна та самая гибкость, способность быстро меняться — мимикрировать в соответствии с экономической средой, трендами и тенденциями. А ОКП — да, метод без методологии, позволяющий стоять на месте, дрейфуя к вымершим «динозабрам».
(53) гибкость стоит выше — чем наполнять план/бэклог. Я про то, что бэклог+спринт = ОКП. Внутри спринта гибкости нет, в части выбора задач для релиза.
Здоровье прекрасное, спасибо. Придумал свой способ сброа веса. Скинул десятку без фитнеса и диет. Еще двадцатка впереди.
(54)
Не надо торопиться, не надо волноваться, а то все назад придет с дополнительным бонусом )))
(51) Именно. Но Аджайл — это набор гибких методик, а Скрам — это достаточно жёсткий фреймворк, разница значительная…
(55) нет, я проверил уже. Месяц набирал вес обратно, за 3 дня снова скинул.
(57) дфиичонки должны подтянуться, ибо тут какой-то метод похудения от 1c-intelligence просто нереальный ))) Скинуть за ТРИ дня ДЕСЯТЬ кг можно только через липосакцию (моя такая ИМХа)
(58) девчонки уже подтянулись.
Я не точно написал — за месяц не десятку обратно набрал, а шесть кг. Они и ушли за три дня.
(59) Лучшего рецепта для похудания, кроме как жрать меньше, нет :))
От себя не убежишь.
(59)
Я не точно написал — за месяц не десятку обратно набрал, а шесть кг. Они и ушли за три дня.
Так делись с обществом 🙂 Хотя, самый эффективный, пожалуй, метод Артемия Лебедева