А какой смысл на daily обсуждать проблемы, которые не могут быть решены командой? Если есть кто-то вне команды, кто может их решить - надо его и дергать, как появилась проблема.
Потому что daily это встреча для инспекции текущего состояния releasable increment и того что мешает полностью достичь цели.
Никто не сказал что их нельзя решить вне daily, но если они есть daily - это крайний момент для такого действия. Последний рубеж обороны для того чтобы увидеть наличие внешней зависимости (что исключительная ситуация для Scrum team, она ж по определению cross-functional, то есть обладает всеми знаниями и навыками для достижения цели).
Простой чат команды решает ту же задачу, но лучше и быстрее, для автономных команд. Скрам как раз для автономных команд. :-) Для слабых команд - предсказательный процесс, менеджмент и делегация исполнения, а не принятия решения. Собственно в статье такой и описан - набор мини-водопадов. То что поставка инкрементальна и итеративна - не делает ее Agile. У каждой коровы есть вымя, но то что имеет вымя - не обязательно корова :-)
ChatOps кстати прекрасный вариант работы, но тут надо учитывать что ChatOps из другой оперы, это уже не эмпирические процессы, это триаж по Cynefin, зона хаоса.
Потому что на самом деле по Scrum Guide там обсуждают impediments. А impediment это препятствие на пути к цели которое не может быть устранено только силами команды.
То что можно решить силами команды - отдано на откуп команде, в рамках автономии команды и конечно же решается сразу. Скрам ничем не противоречит здравому смыслу, это его вольные интерпретации огромным количеством Scrum Master - часто противоречат :-(
Если говорить о статье - то в принципе я уже сказал - у вас прекрасно исполненное описание ответа на вопрос как в отрыве от что и зачем.
В отрыве настолько что некоторые вещи оказываются собственной противоположностью тому что они есть в SG, а какие-то оставляют такой простор для интерпретации что прям ой.
Проведите мысленный эксперимент - задайте себе вопрос чем описанная вами система отличается от итеративной и инкрементальной поставки, которые существовали задолго до появления Scrum, например в Rational Unified Process. А отличие есть, не стоило бы трудов придумывать новые названия для того же, не те люди придумывали Scrum чтобы перелицевать старое знакомое просто лишь бы было свое.
А это отличие - в том что RUP это предсказательный метод, основанный на декомпозиции и плане, пусть и реализуемом итеративно и с инкрементальной поставкой. А Scrum - это цепочка экспериментов по снижению сложности, которая не дает возможности сделать декомпозицию и написать требования и план.
Бэклог состоит из PMI размером не более спринта и упорядочен по приносимой ценности
Работа берется только из бэклога
Причем он именно accountable - ему порвут жопу если этого нету, это ничего не говорит о том что разработчики не могут это делать. Более того - не в самом SG, но в материалах из вменяемых источников (рекомендованных например для подготовки к экзаменам или в книгах авторов скрама) - настоятельно рекомендуется их вовлекать.
Причина по которой бизнеса нет на daily - focus. Команда работает в сложной среде, то есть изучает сложную проблему через серию экспериментов, и вмешательство бизнеса в эксперимент - искажает результаты, то есть мы ни фига не узнаем, сложности не снижаем.
Так что причин у бизнеса лезть в дейли может быть две
Нет доверия команде через предыдущий успешный опыт или прозрачность того что происходит (смотрим обязанности Scrum Master, там прямо про отвечает за transparency) - потому что мы доверяем или тому что уже работало или там где понимаем что происходит.
Или цикл спринта слишком длинный выбран для текущей сложности системы, и цели/вводные данные меняются быстрее чем мы их инспектируем через цикл planning-review. И если даже неделя недостаточно коротко - то мы не зоне сложности, мы в хаосе.
А строится Scrum на предпосылке что у нас таки сложность, а не хаос - то есть время учиться у нас есть. Потому что если нету - то нам нужен не эмпирический метод, а триаж, с еще более коротким циклом, там уже часами исчисляется, как описано например в у Ким в “Настольной книге DevOps”
Статус задачи с точки зрения daily может быть одним из двух
Результат уже соответствует definition of done (готово)
Результат еще не соответствует definition of done (не готово)
Варианта готово на 50% тут нету, или да или нет.
Но на самом деле в скраме в принципе нету понятия задача и этому есть объяснение. Весь скрам-гайд начинается со слов “легковесный фреймворк для решения сложных задач в сложных окружениях”
Сложный (курим Cynefin, часть материалов по подготовке к PSM2) - это означает что нельзя оценить/понять/предсказать через разделение целого на части. А задача - это как раз инструмент декомпозиции - то есть анализа путем разделения целого на части!
Так а дальше все просто:
или у вас можно сделать план через декомпозицию, и можно инспектировать следование плану, а значит предсказывать достижение цели, но тогда у вас не сложная система, и вы скрам используете не там и не так как он задуман
или у вас сложная система или сложное окружение, и тогда вы сами себя обманываете проверяя следование плану, потому что ни понять целое через части, ни предсказать вы по определению не можете.
Тут весь секрет в самом начале SG, в понятии сложности ради которой Скрам, эмпирическом методе на котором основывается скрам, и трех колоннах.
Короче классическая проблема познания - три вопроса - зачем, что и как. Первые два сложные, третий простой, и большинство не парится первыми двумя и фокусируется на третьем, как в вашей статье
Если захотите реально узнать - есть прекрасная статья, из списка материалов по подготовке к PSM2/PSM3 Кристина Вервейса из Либераторов (Liberators) - “Что такое сложность и на фига вам на самом деле скрам”. Можно найти на их medium, или если проще на русском - я ее переводил для habr еще лет несколько назад.
The purpose of Daily Scrum is to inspect progress toward Sprint Goal.
Обсуждение проблем/блокеров это скорее всего была реализация только третьей части рекомендованной структуры Daily которая была в SG до 2020 года, ну там где три вопроса:
Что уже сделано
Что еще надо сделать
Что у нас за преграды на пути к достижению цели
При разработке SG 2020 оставлять эти вопросы или нет было одним из самых горячих споров, и в итоге склонились к тому что большинство команд не правильно понимает вопросы про сделано/еще сделать подменяя их “чему уже делали” и “что еще будем делать” - то есть инспекция занятости, а не результатов, поскольку народ вольно интерпретировал термин done, хотя он четко определен - done это то что соответствует definition of done, а значит может быть частью releasable increment.
Daily дословно нужен для инспекции того насколько УЖЕ достигнута цель спринта. Если вы к ней все еще идете то весь daily это “цель все еще никак не достигнута, вообще на ноль процентов, и у нас есть impediment - мы продолжаем делать водопад зачем-то обзывая его скрамом”.
То что вам написали выше - это как раз признак очень хороший того что там скрам с такими дейли и не пахнет. Людям которые действительно каждый день фиксируют приближение и есть что показать уже работающее - вот тем daily еще как интересен, они его сами организуют. А если там обсуждается как мы следуем планам и как мы ударно трудимся - то это именно то что выше и описали - бесполезная трата времени отвлекающая людей от чего-нибудь полезного и нужная только менеджерам и скрам-мастеру и только для того чтобы ощутить свою нужность :-)
Скрам фреймворк для решения сложных проблем в сложных окружениях. Это цитата из самого начала. При отсутствии сложности (причем в строгом научном понимании - когда проблему нельзя решить путем разделения ее на меньшие, то есть через декомпозицию) - скрам действительно на фиг не нужен, есть другие, более эффективные способы работы.
Если ваш скрам мастер был не знаком с cynefin подходом от IBM и пихал скрам не потому что он реально нужен, а потому что можно - то все правильно сделали :-)
Хотя забавно - ретро как раз мало имеет отношения к сложности, это кусок пришедший туда из Lean и пути постоянного улучшения (Gemba Kaizen). Возможно для проекта ваш процесс и был идеальным и улучшать его - растрачивать деньги, но инженерия без развития - это медленная смерть, так что предположу что на самом деле вы просто делаете continuous improvement просто другим способом.
Статья не про скрам, а про то как большинство (не)понимают скрама поскольку первую, самую важную часть пропускают и фокусируются как при помощи прикольных новых названий построить старый добрый процесс как привыкли.
Да и читают скрам-гайд явно не глазами. Для начала в скраме нет ничего про релизы, есть про releasable increment. Релиз это всегда решение заказчика, а дело команды каждый раз отдавать заказчику то что технически пригодно к постановке на прод, если заказчик решит что функционала уже достаточно.
А вот ситуация в которой 20 процентов функционала уже можно запускать, потому что 80 процентов потребностей уже покрыто и на системе можно зарабатывать уже сейчас - ничем не противоречит ни опыту, ни здравому смыслу, ни потребностям заказчика.
Так вот колесо вполне себе должно быть и на самом деле на производстве является releasable increment - его можно взять и использовать прямо сейчас, а не ждать пока вся машина не будет собрана чтобы проверить что колесо тоже ничего. :-) Да и любая нормальная команда по хорошему отлаживает каждый кусок продукт до prod grade не дожидаясь финального тестирования, чтобы сделать и уже не возвращаться. А кто этого не делает, тому увы и скрам не помогает.
Переизобретение позднего связывания. Собственно тот случай когда свои шишки набивать нету необходимости - достоинства и недостатки позднего связывания, особенно как в данном случае "на стероидах" - давно набиты.
Hint: начать можно с простого - ошибка в написании имени метода выявляется только при запуске приложения. В то время как уже практически доказано что shift left подход (обнаруживать ошибки как можно раньше) - дает видимое увеличение качества и при ускорении time to market - зачем-то делается shift to right. Дальше можно поразвивать эту мысль, например в сторону что произойдет со статическим анализом что качества, что безопасности кода.
Мотивация понятна - предложенный путь дает небольшую экономию времени разработчика (но не времени до вывода на прод). За это кстати надо тоже сказать спасибо метрикам типа velocity которые внедряют псевдо-скрам-мастера, или еще хуже - утилизации (вообще коробит когда про людей говорим) вместо бизнес-ориентированных метрик того же Evidence Management Guide.
Так что чисто технически - действительно интересная работа, но прикладной смысл далеко не очевиден.
Частично справедливое замечание, но есть один нюанс.
Работа с клавиатуры действительно быстрее работы мышкой, если обладаешь навыком слепой печати. Я не любитель vim, но с Visual Studio работаю схожим способом - с клавиатуры. Даже исследования есть по этому поводу, там речь от разнице в двое между мышкой и клавиатурой по скорости.
Раз уж отсылаются к мастеру, то прям просится другая цитата оттуда:
“А сегодня я нашел два способа завязывать шнурки, один хорошо чтобы ходить, другой - что бы падать”
Старый код, конечно, попахивал, после рефакторинга - завонял. Раньше логика зависимая от строковой константы была хотя бы стыдливо спрятана в API, а теперь торчит наружу, поджидая неосторожного джуна или что еще хуже - клиента, чтобы тот выстрелил себе в ногу. И главное что статическим анализом кода такое уже не поймать, только дебаг, только хардкор, причем обязательно с заходом в функцию, чтобы понять чеж там происходит. “SOLID? Never heard about…”
В чем смысл называть итерацию, построенную по принципам последовательной разработки - спринтом? Возможно куда проще будет и команде и заказчику - если работать по принципам предсказательного управления проектами (в простонародье - водопада) в рамках процесса, разработанного именно для этой модели. MSF там или RUP. Тем более что когда нет непредсказуемости в требованиях и условиях выполнения - эти модели дают результат быстрее и дешевле. Да и изобретать ничего не надо будет - тестовые сценарии скажем всегда были неотъемлимой частью варианта использования в RUP, а тест-дизайнер был вовлечен в процесс управления требованиями и изменениями.
Про неопределенность - самая ценная фраза... ППКС, в это и есть смысл Аджайл и разница с предсказательным подходом который зачем-то называют водопадом. :-) Хотя суть именно в этом - можем уверенно предсказать - то не нужен Аджайл. Не можем - не сработает никакой водопад.
А насчет процесс или люди - они ж не зря приписали сразу же после 4-х пунктов: "мы не отрицаем важности того что справа, но ценим то что слева больше". Как раз видимо предполагая что будут интерпретации манифеста в стиле статьи - противопоставлением людей и взаимодействий процессам и инструментам. :-(
Статья написана про распространенную проблему - о том как “делают Ажайл ради Ажайла”, не понимая ни сути, ни цели. Проблема действительно есть, и проблема действительно легко выявляется простой проверкой применяются ли на самом деле 4 ценности и 12 принципов. Если бы статья этим ограничилась - была бы просто шикарная, полезная статья. И хороший эталонный образец мышления как его хотят от Аджайл команд.
Но с тем что дальше, когда начали жарить… Пережарили. К сожалению Аджайл хорошего кода и не мешания программистам - ничуть не лучше и не ближе к тому что описано в манифесте. Соавтор скрама и один из авторов манифеста, Кен Швайбер в своей книге очень четко сказал про “не мешать”, объясняя смысл тайм-боксов: “ничто так не стимулирует творчество как веревка на шее”.
Люди о которых шла речь и ради которых задумывался аджайл вообще и скрам в частности - не исполнители. Это пользователи. Это именно для них создается работоспособный продукт, это с ними взаимодействие важнее формальных документов, а они сами - важнее красивого процесса. Собственно Швайбер и пошел дальше, развив идеи в EBM - Evidence-Based Management (управление на основе доказательств). Мы работаем ради того, чтобы принести пользу потребителям. Это и есть профессионализм (ага, то самое “скрам-команда должна состоять из мотивированных профессионалов”). И измеряют наш успех не по крутости и чистоте кода. А по удовлетворенности конечного пользователя. В этом плане Аджайл как раз не за красивый код. Слово которое там постоянно - just enough. То код ровно настолько хороший, чтобы принести требуемую пользу. И ни граммом больше.
Ну а в остальном выше правильно сказали - и про Shu-Ha-Ru, принцип привнесенный в Agile еще одним подписантом - Алистером Коберном. О том что конкретная техника не цель, а отправная точка. И да, глупость считать ее целью. Но не меньшая глупость начинать сразу с изобретения велосипеда. Впрочем, те же PMI в Disciplined Agile не просто так постоянно повторяют что их плейбук - это начальная точка, а не цель :-) Видно наелись.
Ну и в комментарии выше - есть самая ценная фраза, но боюсь большинство ее пропустило. Аджайл о том когда непонятно. По науке - когда мы столкнулись со сложной системой, которую не способны понять и предсказать своим ограниченным умом. Именно поставка результата, при минимизации потерь, в условиях когда предсказать нельзя - и есть цель. Если смотреть на это так - станет понятнее многое. От принципа “… через ЧАСТУЮ поставку” (потому что поставка - это ЕДИНСТВЕННАЯ возможность проверить свои предположения) до принципа спринтов - коротких, эффективных и контролируемых экспериментов по проверке гипотез. И оно конечно подход DevOps с ежедневной и даже несколько раз в день поставкой - еще лучше чем спринт, но давайте будем честными - для большинства программистов даже раз в месяц - уже болезненно. Поэтому месяц - хорошая отправная точка. Быстрее всегда лучше будет, но пусть для начала раз в месяц сделают.
Как-то так. И да, я знаю что интерпретация Аджайла в статье греет душу, а то что написал я - с точностью до наоборот. Но если рыть в то что на самом деле писали и говорили те, кто подписал манифест - как-то так оно и выходит. Такие дела.
Сразу оговорюсь, как переводчик, статья описывает применение ПБ именно там где оно нужно, где эффект зависит от реальной командной работы - т.е. работ над сложными проектами (как оно понимается в теории сложности), ситуаций хаоса, создания нового знания (НИОКР). Ничего в статье не утверждает, что ПБ надо делать просто потому что это круто и всем срочно нужно. Статья исключительно о том, что если вам действительно нужна ПБ - то можно избежать, увы, распространенных ошибок. Так бывает когда “коачи” забывают простой принцип, хорошо сформулированный Лайзой Адкинс на W.A.T. (Women in Agile and Technology) в этом году: “Мы не коачи как в психологии, мы не работаем в интересах пациента. Мы здесь чтобы клиенты и компании получили эффективную и работающую команду”.
Само понятие ПБ может “триггерить” тех, кто столкнулся к кривой реализацией. Меня лично подвигла на поиск этого материала ситуация когда, в рамках оказания консультационных услуг, мне пришлось довольно жестко занимать сторону одного-единственного человека в команде, кто не боялся “резать правду-матку”, в то время как остальная команда, манипулируя словечками типа “ПБ”, “токсичность”, “софт-скиллз”, пыталась его натурально заткнуть. И так, к сожалению, тоже бывает. И я искренне понимаю почему что у этого человека, очень талантливого инженера теперь будет не очень реакция на идеи о ПБ.
Так что если кого задело - заранее прошу прощения. Ни разу имел в виду. Наоборот, надеюсь что эта статья даст аргументы для диалога с такими "коачами". Все-таки часто "вон че буржуи пишут" оказывается более весомым аргументом чем просто здравый смысл.
Отличная статья, спасибо!
А какой смысл на daily обсуждать проблемы, которые не могут быть решены командой? Если есть кто-то вне команды, кто может их решить - надо его и дергать, как появилась проблема.
Потому что daily это встреча для инспекции текущего состояния releasable increment и того что мешает полностью достичь цели.
Никто не сказал что их нельзя решить вне daily, но если они есть daily - это крайний момент для такого действия. Последний рубеж обороны для того чтобы увидеть наличие внешней зависимости (что исключительная ситуация для Scrum team, она ж по определению cross-functional, то есть обладает всеми знаниями и навыками для достижения цели).
Простой чат команды решает ту же задачу, но лучше и быстрее, для автономных команд.
Скрам как раз для автономных команд. :-) Для слабых команд - предсказательный процесс, менеджмент и делегация исполнения, а не принятия решения. Собственно в статье такой и описан - набор мини-водопадов. То что поставка инкрементальна и итеративна - не делает ее Agile. У каждой коровы есть вымя, но то что имеет вымя - не обязательно корова :-)
ChatOps кстати прекрасный вариант работы, но тут надо учитывать что ChatOps из другой оперы, это уже не эмпирические процессы, это триаж по Cynefin, зона хаоса.
Хороший набор критериев для первой версии требований, на самом деле. Теперь бы шаг вперед и посмотреть в сторону их поддержки.
RUP скажем или ГОСТ 34 предполагал еще что требования должны быть
Трассируемыми
Изменяемыми
Потому что система документации такой же живой организм как и вся система, и большая часть работы на самом деле будет лежать в изменениях требований.
А вы как у себя делаете управление изменениями?
Потому что на самом деле по Scrum Guide там обсуждают impediments. А impediment это препятствие на пути к цели которое не может быть устранено только силами команды.
То что можно решить силами команды - отдано на откуп команде, в рамках автономии команды и конечно же решается сразу. Скрам ничем не противоречит здравому смыслу, это его вольные интерпретации огромным количеством Scrum Master - часто противоречат :-(
Если говорить о статье - то в принципе я уже сказал - у вас прекрасно исполненное описание ответа на вопрос как в отрыве от что и зачем.
В отрыве настолько что некоторые вещи оказываются собственной противоположностью тому что они есть в SG, а какие-то оставляют такой простор для интерпретации что прям ой.
Проведите мысленный эксперимент - задайте себе вопрос чем описанная вами система отличается от итеративной и инкрементальной поставки, которые существовали задолго до появления Scrum, например в Rational Unified Process. А отличие есть, не стоило бы трудов придумывать новые названия для того же, не те люди придумывали Scrum чтобы перелицевать старое знакомое просто лишь бы было свое.
А это отличие - в том что RUP это предсказательный метод, основанный на декомпозиции и плане, пусть и реализуемом итеративно и с инкрементальной поставкой. А Scrum - это цепочка экспериментов по снижению сложности, которая не дает возможности сделать декомпозицию и написать требования и план.
Кстати нет, ПО отвечает за то что:
У команды есть бэклог
Бэклог состоит из PMI размером не более спринта и упорядочен по приносимой ценности
Работа берется только из бэклога
Причем он именно accountable - ему порвут жопу если этого нету, это ничего не говорит о том что разработчики не могут это делать. Более того - не в самом SG, но в материалах из вменяемых источников (рекомендованных например для подготовки к экзаменам или в книгах авторов скрама) - настоятельно рекомендуется их вовлекать.
Причина по которой бизнеса нет на daily - focus. Команда работает в сложной среде, то есть изучает сложную проблему через серию экспериментов, и вмешательство бизнеса в эксперимент - искажает результаты, то есть мы ни фига не узнаем, сложности не снижаем.
Так что причин у бизнеса лезть в дейли может быть две
Нет доверия команде через предыдущий успешный опыт или прозрачность того что происходит (смотрим обязанности Scrum Master, там прямо про отвечает за transparency) - потому что мы доверяем или тому что уже работало или там где понимаем что происходит.
Или цикл спринта слишком длинный выбран для текущей сложности системы, и цели/вводные данные меняются быстрее чем мы их инспектируем через цикл planning-review. И если даже неделя недостаточно коротко - то мы не зоне сложности, мы в хаосе.
А строится Scrum на предпосылке что у нас таки сложность, а не хаос - то есть время учиться у нас есть. Потому что если нету - то нам нужен не эмпирический метод, а триаж, с еще более коротким циклом, там уже часами исчисляется, как описано например в у Ким в “Настольной книге DevOps”
Статус задачи с точки зрения daily может быть одним из двух
Результат уже соответствует definition of done (готово)
Результат еще не соответствует definition of done (не готово)
Варианта готово на 50% тут нету, или да или нет.
Но на самом деле в скраме в принципе нету понятия задача и этому есть объяснение. Весь скрам-гайд начинается со слов “легковесный фреймворк для решения сложных задач в сложных окружениях”
Сложный (курим Cynefin, часть материалов по подготовке к PSM2) - это означает что нельзя оценить/понять/предсказать через разделение целого на части. А задача - это как раз инструмент декомпозиции - то есть анализа путем разделения целого на части!
Так а дальше все просто:
или у вас можно сделать план через декомпозицию, и можно инспектировать следование плану, а значит предсказывать достижение цели, но тогда у вас не сложная система, и вы скрам используете не там и не так как он задуман
или у вас сложная система или сложное окружение, и тогда вы сами себя обманываете проверяя следование плану, потому что ни понять целое через части, ни предсказать вы по определению не можете.
Тут весь секрет в самом начале SG, в понятии сложности ради которой Скрам, эмпирическом методе на котором основывается скрам, и трех колоннах.
Короче классическая проблема познания - три вопроса - зачем, что и как. Первые два сложные, третий простой, и большинство не парится первыми двумя и фокусируется на третьем, как в вашей статье
Если захотите реально узнать - есть прекрасная статья, из списка материалов по подготовке к PSM2/PSM3 Кристина Вервейса из Либераторов (Liberators) - “Что такое сложность и на фига вам на самом деле скрам”. Можно найти на их medium, или если проще на русском - я ее переводил для habr еще лет несколько назад.
В Scrum Guide однако
The purpose of Daily Scrum is to inspect progress toward Sprint Goal.
Обсуждение проблем/блокеров это скорее всего была реализация только третьей части рекомендованной структуры Daily которая была в SG до 2020 года, ну там где три вопроса:
Что уже сделано
Что еще надо сделать
Что у нас за преграды на пути к достижению цели
При разработке SG 2020 оставлять эти вопросы или нет было одним из самых горячих споров, и в итоге склонились к тому что большинство команд не правильно понимает вопросы про сделано/еще сделать подменяя их “чему уже делали” и “что еще будем делать” - то есть инспекция занятости, а не результатов, поскольку народ вольно интерпретировал термин done, хотя он четко определен - done это то что соответствует definition of done, а значит может быть частью releasable increment.
Вот зачем вы вводите народ в заблуждение?
Daily дословно нужен для инспекции того насколько УЖЕ достигнута цель спринта. Если вы к ней все еще идете то весь daily это “цель все еще никак не достигнута, вообще на ноль процентов, и у нас есть impediment - мы продолжаем делать водопад зачем-то обзывая его скрамом”.
То что вам написали выше - это как раз признак очень хороший того что там скрам с такими дейли и не пахнет. Людям которые действительно каждый день фиксируют приближение и есть что показать уже работающее - вот тем daily еще как интересен, они его сами организуют. А если там обсуждается как мы следуем планам и как мы ударно трудимся - то это именно то что выше и описали - бесполезная трата времени отвлекающая людей от чего-нибудь полезного и нужная только менеджерам и скрам-мастеру и только для того чтобы ощутить свою нужность :-)
Скрам фреймворк для решения сложных проблем в сложных окружениях. Это цитата из самого начала. При отсутствии сложности (причем в строгом научном понимании - когда проблему нельзя решить путем разделения ее на меньшие, то есть через декомпозицию) - скрам действительно на фиг не нужен, есть другие, более эффективные способы работы.
Если ваш скрам мастер был не знаком с cynefin подходом от IBM и пихал скрам не потому что он реально нужен, а потому что можно - то все правильно сделали :-)
Хотя забавно - ретро как раз мало имеет отношения к сложности, это кусок пришедший туда из Lean и пути постоянного улучшения (Gemba Kaizen). Возможно для проекта ваш процесс и был идеальным и улучшать его - растрачивать деньги, но инженерия без развития - это медленная смерть, так что предположу что на самом деле вы просто делаете continuous improvement просто другим способом.
Статья не про скрам, а про то как большинство (не)понимают скрама поскольку первую, самую важную часть пропускают и фокусируются как при помощи прикольных новых названий построить старый добрый процесс как привыкли.
Да и читают скрам-гайд явно не глазами. Для начала в скраме нет ничего про релизы, есть про releasable increment. Релиз это всегда решение заказчика, а дело команды каждый раз отдавать заказчику то что технически пригодно к постановке на прод, если заказчик решит что функционала уже достаточно.
А вот ситуация в которой 20 процентов функционала уже можно запускать, потому что 80 процентов потребностей уже покрыто и на системе можно зарабатывать уже сейчас - ничем не противоречит ни опыту, ни здравому смыслу, ни потребностям заказчика.
Так вот колесо вполне себе должно быть и на самом деле на производстве является releasable increment - его можно взять и использовать прямо сейчас, а не ждать пока вся машина не будет собрана чтобы проверить что колесо тоже ничего. :-) Да и любая нормальная команда по хорошему отлаживает каждый кусок продукт до prod grade не дожидаясь финального тестирования, чтобы сделать и уже не возвращаться. А кто этого не делает, тому увы и скрам не помогает.
Переизобретение позднего связывания. Собственно тот случай когда свои шишки набивать нету необходимости - достоинства и недостатки позднего связывания, особенно как в данном случае "на стероидах" - давно набиты.
Hint: начать можно с простого - ошибка в написании имени метода выявляется только при запуске приложения. В то время как уже практически доказано что shift left подход (обнаруживать ошибки как можно раньше) - дает видимое увеличение качества и при ускорении time to market - зачем-то делается shift to right. Дальше можно поразвивать эту мысль, например в сторону что произойдет со статическим анализом что качества, что безопасности кода.
Мотивация понятна - предложенный путь дает небольшую экономию времени разработчика (но не времени до вывода на прод). За это кстати надо тоже сказать спасибо метрикам типа velocity которые внедряют псевдо-скрам-мастера, или еще хуже - утилизации (вообще коробит когда про людей говорим) вместо бизнес-ориентированных метрик того же Evidence Management Guide.
Так что чисто технически - действительно интересная работа, но прикладной смысл далеко не очевиден.
Частично справедливое замечание, но есть один нюанс.
Работа с клавиатуры действительно быстрее работы мышкой, если обладаешь навыком слепой печати. Я не любитель vim, но с Visual Studio работаю схожим способом - с клавиатуры. Даже исследования есть по этому поводу, там речь от разнице в двое между мышкой и клавиатурой по скорости.
Раз уж отсылаются к мастеру, то прям просится другая цитата оттуда:
“А сегодня я нашел два способа завязывать шнурки, один хорошо чтобы ходить, другой - что бы падать”
Старый код, конечно, попахивал, после рефакторинга - завонял. Раньше логика зависимая от строковой константы была хотя бы стыдливо спрятана в API, а теперь торчит наружу, поджидая неосторожного джуна или что еще хуже - клиента, чтобы тот выстрелил себе в ногу. И главное что статическим анализом кода такое уже не поймать, только дебаг, только хардкор, причем обязательно с заходом в функцию, чтобы понять чеж там происходит. “SOLID? Never heard about…”
Больше, понимаешь, книжек, хороших и разных.
В чем смысл называть итерацию, построенную по принципам последовательной разработки - спринтом? Возможно куда проще будет и команде и заказчику - если работать по принципам предсказательного управления проектами (в простонародье - водопада) в рамках процесса, разработанного именно для этой модели. MSF там или RUP. Тем более что когда нет непредсказуемости в требованиях и условиях выполнения - эти модели дают результат быстрее и дешевле. Да и изобретать ничего не надо будет - тестовые сценарии скажем всегда были неотъемлимой частью варианта использования в RUP, а тест-дизайнер был вовлечен в процесс управления требованиями и изменениями.
Комментарий - золото!
Про неопределенность - самая ценная фраза... ППКС, в это и есть смысл Аджайл и разница с предсказательным подходом который зачем-то называют водопадом. :-) Хотя суть именно в этом - можем уверенно предсказать - то не нужен Аджайл. Не можем - не сработает никакой водопад.
А насчет процесс или люди - они ж не зря приписали сразу же после 4-х пунктов: "мы не отрицаем важности того что справа, но ценим то что слева больше". Как раз видимо предполагая что будут интерпретации манифеста в стиле статьи - противопоставлением людей и взаимодействий процессам и инструментам. :-(
Статья написана про распространенную проблему - о том как “делают Ажайл ради Ажайла”, не понимая ни сути, ни цели. Проблема действительно есть, и проблема действительно легко выявляется простой проверкой применяются ли на самом деле 4 ценности и 12 принципов. Если бы статья этим ограничилась - была бы просто шикарная, полезная статья. И хороший эталонный образец мышления как его хотят от Аджайл команд.
Но с тем что дальше, когда начали жарить… Пережарили. К сожалению Аджайл хорошего кода и не мешания программистам - ничуть не лучше и не ближе к тому что описано в манифесте. Соавтор скрама и один из авторов манифеста, Кен Швайбер в своей книге очень четко сказал про “не мешать”, объясняя смысл тайм-боксов: “ничто так не стимулирует творчество как веревка на шее”.
Люди о которых шла речь и ради которых задумывался аджайл вообще и скрам в частности - не исполнители. Это пользователи. Это именно для них создается работоспособный продукт, это с ними взаимодействие важнее формальных документов, а они сами - важнее красивого процесса. Собственно Швайбер и пошел дальше, развив идеи в EBM - Evidence-Based Management (управление на основе доказательств). Мы работаем ради того, чтобы принести пользу потребителям. Это и есть профессионализм (ага, то самое “скрам-команда должна состоять из мотивированных профессионалов”). И измеряют наш успех не по крутости и чистоте кода. А по удовлетворенности конечного пользователя. В этом плане Аджайл как раз не за красивый код. Слово которое там постоянно - just enough. То код ровно настолько хороший, чтобы принести требуемую пользу. И ни граммом больше.
Ну а в остальном выше правильно сказали - и про Shu-Ha-Ru, принцип привнесенный в Agile еще одним подписантом - Алистером Коберном. О том что конкретная техника не цель, а отправная точка. И да, глупость считать ее целью. Но не меньшая глупость начинать сразу с изобретения велосипеда. Впрочем, те же PMI в Disciplined Agile не просто так постоянно повторяют что их плейбук - это начальная точка, а не цель :-) Видно наелись.
Ну и в комментарии выше - есть самая ценная фраза, но боюсь большинство ее пропустило. Аджайл о том когда непонятно. По науке - когда мы столкнулись со сложной системой, которую не способны понять и предсказать своим ограниченным умом. Именно поставка результата, при минимизации потерь, в условиях когда предсказать нельзя - и есть цель. Если смотреть на это так - станет понятнее многое. От принципа “… через ЧАСТУЮ поставку” (потому что поставка - это ЕДИНСТВЕННАЯ возможность проверить свои предположения) до принципа спринтов - коротких, эффективных и контролируемых экспериментов по проверке гипотез. И оно конечно подход DevOps с ежедневной и даже несколько раз в день поставкой - еще лучше чем спринт, но давайте будем честными - для большинства программистов даже раз в месяц - уже болезненно. Поэтому месяц - хорошая отправная точка. Быстрее всегда лучше будет, но пусть для начала раз в месяц сделают.
Как-то так. И да, я знаю что интерпретация Аджайла в статье греет душу, а то что написал я - с точностью до наоборот. Но если рыть в то что на самом деле писали и говорили те, кто подписал манифест - как-то так оно и выходит. Такие дела.
Ну, если учесть насколько западная тусовка в гуманитарных науках повернута на левых идеях - это совершенно не удивительно.
Да и принципе кто помнит как делался нормальный НИОКР в СССР, глядя на Agile легко заметит, что там очень много "хорошо забытого старого". :-)
Сразу оговорюсь, как переводчик, статья описывает применение ПБ именно там где оно нужно, где эффект зависит от реальной командной работы - т.е. работ над сложными проектами (как оно понимается в теории сложности), ситуаций хаоса, создания нового знания (НИОКР). Ничего в статье не утверждает, что ПБ надо делать просто потому что это круто и всем срочно нужно. Статья исключительно о том, что если вам действительно нужна ПБ - то можно избежать, увы, распространенных ошибок. Так бывает когда “коачи” забывают простой принцип, хорошо сформулированный Лайзой Адкинс на W.A.T. (Women in Agile and Technology) в этом году: “Мы не коачи как в психологии, мы не работаем в интересах пациента. Мы здесь чтобы клиенты и компании получили эффективную и работающую команду”.
Само понятие ПБ может “триггерить” тех, кто столкнулся к кривой реализацией. Меня лично подвигла на поиск этого материала ситуация когда, в рамках оказания консультационных услуг, мне пришлось довольно жестко занимать сторону одного-единственного человека в команде, кто не боялся “резать правду-матку”, в то время как остальная команда, манипулируя словечками типа “ПБ”, “токсичность”, “софт-скиллз”, пыталась его натурально заткнуть. И так, к сожалению, тоже бывает. И я искренне понимаю почему что у этого человека, очень талантливого инженера теперь будет не очень реакция на идеи о ПБ.
Так что если кого задело - заранее прошу прощения. Ни разу имел в виду. Наоборот, надеюсь что эта статья даст аргументы для диалога с такими "коачами". Все-таки часто "вон че буржуи пишут" оказывается более весомым аргументом чем просто здравый смысл.
Фух, дописал. Cheers y'all!
Соглашусь, вы правы. И тут тоже "нет ничего нового под солнцем"