Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 52
Спасибо!
Кто прочитал статью, давайте по-полемизируем?
Какие практики XP вы используете? Почему не нравится Scrum? Используете ли метрики? А тулзы какие?..
Какие практики XP вы используете? Почему не нравится Scrum? Используете ли метрики? А тулзы какие?..
BVT, Gated checkins. Скрам не нравится излишней бюрократией — все эти ретроспективы, бёрндауны, коммитменты, форкасты — тоска полная. В скраме рулит только одно — короткие спринты с обязательными инкрементами. Тогда есть выхлоп. Иначе все скатывается в обычный вотерфол, со всеми вытекающими. Как говорится, «на заборе тоже пишут»…
Мне всегда казалось, что базовые скрам практики очень простые, особенно когда команда была большой. Но сейчас у нас команда фактически из двух программистов и product owner'а, поэтому скрам выглядит тяжеловесно. У нас регулярные демо и практически постоянно парное программирование и разработка через тесты (пишем бекенд на Python и клиентсайд на Adobe AIR под Android).
А где вы поднимаете вопросы о проблемах команды? Ну что-то вроде ретро? Как механизм «постоянного совершенствования процессов» у вас реализован в команде?
А где вы поднимаете вопросы о проблемах команды? Ну что-то вроде ретро? Как механизм «постоянного совершенствования процессов» у вас реализован в команде?
У нас скрам заработал, только когда от него остались стендапы и мягкое еженедельное планирование (даже без оценки историй). Иначе действительно, бюрократизация все съедает.
Основная проблема в scrum в том, что там нет места для НИОКР. С точки зрения организации работы в известном направлении известным образом — всё отлично.
А если надо подумать? Что такое «подумать» с точки зрения scrum как оно учитывается и оценивается? Куда попадают десятки часов, потраченные на проверку гипотез, изучения поведения чужого чёрного ящика?
В этом месте зияет дыра. До некоторого предела можно прикрывать моделью scrum (story 'придумать модель взаимодействия' на два сторипоинта на следующий спринт, ага), но дальше оно расползается в один из нескольких вариантов — либо кто-то берётся за дело (и портит себе показатели), либо все занимаются чем сказали, а проблему старательно обходят.
А если надо подумать? Что такое «подумать» с точки зрения scrum как оно учитывается и оценивается? Куда попадают десятки часов, потраченные на проверку гипотез, изучения поведения чужого чёрного ящика?
В этом месте зияет дыра. До некоторого предела можно прикрывать моделью scrum (story 'придумать модель взаимодействия' на два сторипоинта на следующий спринт, ага), но дальше оно расползается в один из нескольких вариантов — либо кто-то берётся за дело (и портит себе показатели), либо все занимаются чем сказали, а проблему старательно обходят.
Подумать с точки зрения Scrum это задачи типа Spike.
Это жесткий таймбокс, в котором члены команды должны получить артифакт (спеку, документацию, хеллоуолд), который описывал бы решение этой задачи таким образом, чтобы ее можно было уже оценить во времени.
Либо бесконечные спайки :)
Это жесткий таймбокс, в котором члены команды должны получить артифакт (спеку, документацию, хеллоуолд), который описывал бы решение этой задачи таким образом, чтобы ее можно было уже оценить во времени.
Либо бесконечные спайки :)
Вы написали, а я понял, в чём проблема.
Проблема scrum в том, что в нём в качестве определяющей аксиомы написано «мы знаем, что хотим получить до того, как ткнём start progress». Когда цель ясна, дальше её можно дробить до состояния «нельзя не выполнить».
Но жизнь — она не такая. Бывают баги размером в пяток эпиков, причём до того, как описать баг (хоть как-то, по описанию, выходящий за пределы «иногда не работает») нужно потратить неизвестно сколько времени, неизвестно сколько усилий и вообще ничего не известно.
scrum с мелким делением на выполнимые задачи совершенно закрывает любые пути к поиску неизвестного. А самое обидное, что как только неизвестное становится известным, дальше это чистой воды scrum и всё понятно как дальше планировать. Более того, когда там чистой воды scrum, то становится не понятно «а что он там две недели валандался?».
Я решения этой проблемы, в рамках планирования, не знаю.
Проблема scrum в том, что в нём в качестве определяющей аксиомы написано «мы знаем, что хотим получить до того, как ткнём start progress». Когда цель ясна, дальше её можно дробить до состояния «нельзя не выполнить».
Но жизнь — она не такая. Бывают баги размером в пяток эпиков, причём до того, как описать баг (хоть как-то, по описанию, выходящий за пределы «иногда не работает») нужно потратить неизвестно сколько времени, неизвестно сколько усилий и вообще ничего не известно.
scrum с мелким делением на выполнимые задачи совершенно закрывает любые пути к поиску неизвестного. А самое обидное, что как только неизвестное становится известным, дальше это чистой воды scrum и всё понятно как дальше планировать. Более того, когда там чистой воды scrum, то становится не понятно «а что он там две недели валандался?».
Я решения этой проблемы, в рамках планирования, не знаю.
К сожалению я тоже не знаю решения этой проблемы. Это и демотивирует в Scrum'е. Но это не повод ставить на agile как определенной системе ценностей и философии крест.
Для меня лично трудно найти конечную измеримую цель, и оценить сложность (трудозатраты?), к примеру, в разработке «принципиально нового космического аппарата» или «модуля памяти на основе квантовой спи́новой жидкости». Да и ценность таких оценок, если разброс может быть от одного года до 8 лет?..
Для меня лично трудно найти конечную измеримую цель, и оценить сложность (трудозатраты?), к примеру, в разработке «принципиально нового космического аппарата» или «модуля памяти на основе квантовой спи́новой жидкости». Да и ценность таких оценок, если разброс может быть от одного года до 8 лет?..
Да опять-таки ни причём здесь Scrum.
Ни одна из существующих методологий не способна это учесть и не возможно это вообще под какие-либо универсальные рамки подогнать.
Это иррационально, субъективно, и ваша роль как руководителя (команды или самого себя) просто пронаблюдать такие вещи и вывести субъективные закономерности.
Если изначально всё детально разбито на операции, то какая к чёрту разница, как вы дальше будете решать эту задачу.
Ни одна из существующих методологий не способна это учесть и не возможно это вообще под какие-либо универсальные рамки подогнать.
Это иррационально, субъективно, и ваша роль как руководителя (команды или самого себя) просто пронаблюдать такие вещи и вывести субъективные закономерности.
Если изначально всё детально разбито на операции, то какая к чёрту разница, как вы дальше будете решать эту задачу.
вывести субъективные закономерности.
Вы не могли бы пояснить, что вы под этим имеете ввиду?
Я имел в виду, что в реальности приходится сталкиваться с такими проектами, когда невозможно внятно разбить его на задачи, оценить сложность, пока сама задача не будет доведена до определённого этапа. Это вполне логично, но попробуйте объяснить это заказчику, к которому вы пришли и рассказываете, что на его деньги занимались исследованием и пришли к отрицательному результату. В результате субъективно под заказчика придётся подстраиваться.
Далее, для оценки трудозатрат приходится пользоваться определёнными моделями. Все эти модели опираются на вполне определённую статистику и подразумевают большое количество участников проекта. Именно тогда субъективные факторы (плохое настроение ведущего инженера в прошлую пятницу, свадьба шурина системного архитектора и т.п.) взаимоуничтожатся, попав под статистическое усреднение. Останутся только объективные факторы.
Но если у вас участников проекта мало (а таких проектов подавляющее большинство), тогда при применении какой-либо модели субъективные факторы буду вполне соизмеримыми с объективными факторами. И приходится уже учитывать их тоже. Например, ведущий инженер по понедельникам и четвергам не может задержаться на работе, потому что у него по этим дням тренировка, но обычно он с радостью задерживается. Или производительность системного архитектора после выходных ниже, чем в среду, но выше, чем в пятницу.
Далее, для оценки трудозатрат приходится пользоваться определёнными моделями. Все эти модели опираются на вполне определённую статистику и подразумевают большое количество участников проекта. Именно тогда субъективные факторы (плохое настроение ведущего инженера в прошлую пятницу, свадьба шурина системного архитектора и т.п.) взаимоуничтожатся, попав под статистическое усреднение. Останутся только объективные факторы.
Но если у вас участников проекта мало (а таких проектов подавляющее большинство), тогда при применении какой-либо модели субъективные факторы буду вполне соизмеримыми с объективными факторами. И приходится уже учитывать их тоже. Например, ведущий инженер по понедельникам и четвергам не может задержаться на работе, потому что у него по этим дням тренировка, но обычно он с радостью задерживается. Или производительность системного архитектора после выходных ниже, чем в среду, но выше, чем в пятницу.
Проблема scrum в том, что в нём в качестве определяющей аксиомы написано «мы знаем, что хотим получить до того, как ткнём start progress». Когда цель ясна, дальше её можно дробить до состояния «нельзя не выполнить».
Не согласен. Там аксиома скорее такова, что мы мало что знаем о story на её старте и с помощью постоянного общения с PO мы уточняем детализацию в течении спринта. А если ещё и работать по правилу «Стори завершена, когда PO сказал что она завершена», то это только стимулирует общение.
Возражения на счет того, что PO будет в таком случае злоупотреблять не принимаю, т.к. в данном случае есть противопоставление PO команде, а это изначально неправильная постановка процесса разработки — горе такому скрам внедрителю.
Граница забора и обеда должна быть решена на планировании спринта. «Стори завершена, когда PO сказал что она завершена» очень размытый критерий. Но даже если и так, acceptance criteria все равно должны быть решены именно на планировании. Иначе вы нарушаете ритм команды (если вносите изменения постоянно), и эффективность падает.
Еще о User Story от Майка Кона: www.mountaingoatsoftware.com/presentations/introduction-to-user-stories
Еще о User Story от Майка Кона: www.mountaingoatsoftware.com/presentations/introduction-to-user-stories
Введение такой границы скатывает нас от agile опять в сторону «я хочу четкое ТЗ». С PO надо уметь работать, его не просто надо заставить подписаться под DOD на планнинге, его надо изредка приглашать на Daily Scrum, советоваться с ним (из разряда: хотим сделать так, это будет нормально или нет). И PO должен действовать адекватно и понимать, когда его хотелка разрастается, стоит ли завести новую стори, просить сделать доп. мелочи или договориться с командой об аборте спринта. В этом и заключается гибкий подход.
Кстати, у Майка Кона книга User Stories Applied на русский переведена, я даже небольшой обзор по ней делал: pimenaus.livejournal.com/12614.html
Кстати, у Майка Кона книга User Stories Applied на русский переведена, я даже небольшой обзор по ней делал: pimenaus.livejournal.com/12614.html
Либо РО в этом случае божественное создание, либо это такая завуалированная система типового «ой, вот тут вот нужно поменять местами кнопки, а ещё там отчёт неправильно генерируется, и вот тут вот списания нужно не по месяцу делать, а по суткам, но кнопочки лучше всё-таки местами переставить».
Я ж говорю про ситуацию, когда человек видит, что что-то не так, но что именно — не может сказать. И до момента когда он может сказать должно пройти довольно много времени «непонятно на что». Scrum это всё отметает как невозможное.
Я ж говорю про ситуацию, когда человек видит, что что-то не так, но что именно — не может сказать. И до момента когда он может сказать должно пройти довольно много времени «непонятно на что». Scrum это всё отметает как невозможное.
Да не божественное он создание. Он просто один из пассажиров лодки которая не должна утонуть, поэтому он должен рационально оценивать свои действия.
На счет стори, которые «фиг знает что делать» — это тоже самое, что и исследовательские стори, надо планировать в своей работе задачи по выявлению причин (да это не marketable feature, мы понимаем, что жизнь не идеальна). Здесь главное не оставлять стори в виде проблемы, а формулировать дальнейшие действия по её решению (не надо из спринта в спринт одну же стори дёргать по беклогам, надо эпик разбивать по шагам в зависимости от появляющихся или отметаемых гипотезах). И в данном случае я бы не наказывал команду за фейлы нескольких спринтов, когда они тыкаются как слепые котята в поиске решения. Тут надо четко понимать, когда нет результата по общесистемным причинам, а когда нет результата по особым причинам.
Проще всего скатиться обратно в состояние «научного центра», когда работу невозможно спрогнозировать и непонятно когда результат будет. Scrum в отличии от метода «научного цента» хотя-бы на момент формирования беклога заставляет задуматься о следующих шагах в решении эпичной проблемы.
На счет стори, которые «фиг знает что делать» — это тоже самое, что и исследовательские стори, надо планировать в своей работе задачи по выявлению причин (да это не marketable feature, мы понимаем, что жизнь не идеальна). Здесь главное не оставлять стори в виде проблемы, а формулировать дальнейшие действия по её решению (не надо из спринта в спринт одну же стори дёргать по беклогам, надо эпик разбивать по шагам в зависимости от появляющихся или отметаемых гипотезах). И в данном случае я бы не наказывал команду за фейлы нескольких спринтов, когда они тыкаются как слепые котята в поиске решения. Тут надо четко понимать, когда нет результата по общесистемным причинам, а когда нет результата по особым причинам.
Проще всего скатиться обратно в состояние «научного центра», когда работу невозможно спрогнозировать и непонятно когда результат будет. Scrum в отличии от метода «научного цента» хотя-бы на момент формирования беклога заставляет задуматься о следующих шагах в решении эпичной проблемы.
Проблема в том, что scrum — это для группы людей. То есть как только вы начинаете играть в scrum вдвоём или даже в одиночестве, оно превращается в нелепую бюрократию. Вместо того, чтобы пойти и потыкать кто-то должен пойти, написать это (причём не в виде двух-трёх слов) — к этому моменту любой энтузиазм пропадает.
Мне кажется, попытка притягивать scrum (как систему нацеленную на достижение конкретных результатов) на свободный поиск — это ошибка. Можно переименовывать тип issue как угодно, но вот набор проблем, которые не устранить:
1) Тему исследовательского issue сформулировать в нормальном режиме можно только по завершению исследования.
2) Сколько оно займёт времени не известно.
3) Многие итерации слишком короткие или трудноформализуемые, чтобы быть выписанными
4) В процессе поиска часто приходится возвращаться к, казалось бы, уже законченной области.
5) Терминология области часто становится понятной после изучения/исследования.
Всё это приводит к простой мысли: если есть такие вещи, то их не следует пытаться растянуть по бюрократическому механизму — проще зарезервировать время в течение спринта на свободный поиск.
Мне кажется, попытка притягивать scrum (как систему нацеленную на достижение конкретных результатов) на свободный поиск — это ошибка. Можно переименовывать тип issue как угодно, но вот набор проблем, которые не устранить:
1) Тему исследовательского issue сформулировать в нормальном режиме можно только по завершению исследования.
2) Сколько оно займёт времени не известно.
3) Многие итерации слишком короткие или трудноформализуемые, чтобы быть выписанными
4) В процессе поиска часто приходится возвращаться к, казалось бы, уже законченной области.
5) Терминология области часто становится понятной после изучения/исследования.
Всё это приводит к простой мысли: если есть такие вещи, то их не следует пытаться растянуть по бюрократическому механизму — проще зарезервировать время в течение спринта на свободный поиск.
для двух человек не надо играть в скрам, вы правильно заметили, что это становится бюрократией
под перечисленными функциями вы описали не только работу по НИОКР но и саму рутинную работу аналитика :)
по моему опыту — нормально можно запихнуть в scrum.
А про резерв времени, а почему бы просто не отвести весь спринт свободному поиску? по результатам спринта будет какой-то результат (список направлений для дальнейшего поиска или ещё что-то) по нему можно будет сделать ещё набор стори.
под перечисленными функциями вы описали не только работу по НИОКР но и саму рутинную работу аналитика :)
по моему опыту — нормально можно запихнуть в scrum.
А про резерв времени, а почему бы просто не отвести весь спринт свободному поиску? по результатам спринта будет какой-то результат (список направлений для дальнейшего поиска или ещё что-то) по нему можно будет сделать ещё набор стори.
А расскажите как вы это «запихнули» в скрам?
Глобально, нужно выбрать из готовых или написать свой компонент для распознавания языков и кодировок.
Делалась стори на сбор и анализ существующих алгоритмов (на выходе должен быть артефакт — отчет с показателями быстродействия и поддерживаемыми языками и кодировками). Далее была стори на проработку архитектуры своего решения.
Стори на «наколенный» модуль по своему решению.
Стори по тестированию быстродействия и определения потенциала своего модуля
дальше приняли решение пилить свой модуль
Стори по рефакторингу для доведения своего модуля до продакшн системы
Стори по оптимизации и увеличению скорости работы
Делалась стори на сбор и анализ существующих алгоритмов (на выходе должен быть артефакт — отчет с показателями быстродействия и поддерживаемыми языками и кодировками). Далее была стори на проработку архитектуры своего решения.
Стори на «наколенный» модуль по своему решению.
Стори по тестированию быстродействия и определения потенциала своего модуля
дальше приняли решение пилить свой модуль
Стори по рефакторингу для доведения своего модуля до продакшн системы
Стори по оптимизации и увеличению скорости работы
Странно что рефакторинги и тестированию быстродействия были вынесены в Story. Product Owner точно знал об этом? Как они были сформулированы примерно?
По «книжке» надо делать рефакторинг просто так, во время спринта, но это не всегда получается (сами знаете, что может быть epic рефакторинг). Подобные вещи составляют технический долг проекта. PO объяснили суть технического долга и изредка проводили консолидацию разных технических доработок в отдельные стори.
А это «Изредка» определялось профилем нагрузки команды.
А это «Изредка» определялось профилем нагрузки команды.
Для ИТ в целом это очень больная тема. И Scrum как таковой тут ни причём.
Очень многие авторы предлагают определённые способы, но далеко не все из них применимы в принципе и ни одна не применима в чистом виде. А учитывая то, что все без исключения авторы почему-то не приводят примеров сложнее и реальнее, чем «Hello, World!», то на выходе получается едва ли не бесполезная информация.
Я уже молчу о том, что в очень многих случаях статьи об этом — банальное жонглирование модными терминами с непонятной целью.
Зачастую компании и команды внутри них организованы таким образом, что затруднительно оценивать что-либо — будь то сложность проекта, его сроки, бюджет. И так же сложно осуществлять мониторинг и прогнозирование. Большинство умозаключений, которые можно сделать в ходе наблюдения за проектом, являются довольно хрупкими закономерностями, которые очень сильно зависят от слишком большого количества переменных. Более того, многие проекты или компании малы, так что вообще какие-либо закономерности и тренды выявлять опасно, т.к. для команды из пары тройки разработчиков в проекте на 3-4 месяца ошибка оценки можен переваливать за 200%, что никуда не годится. Я к тому, что всё настолько иднивидуально, что рецепт, успешно применяемый в условном IBM, скорее всего не сработает в фирме «Рога и Копыта» с персоналом 20 человек вместе с уборщицей.
Я не говорю, что этим не надо заниматься. Напротив: следует всегда держать руку на пульсе. Но следует больше пользоваться головой и руководствоваться здравым смыслом, нежели упражняться в склонении новомодных терминов. В данном случае Scrum ни причём совершенно.
Очень многие авторы предлагают определённые способы, но далеко не все из них применимы в принципе и ни одна не применима в чистом виде. А учитывая то, что все без исключения авторы почему-то не приводят примеров сложнее и реальнее, чем «Hello, World!», то на выходе получается едва ли не бесполезная информация.
Я уже молчу о том, что в очень многих случаях статьи об этом — банальное жонглирование модными терминами с непонятной целью.
Зачастую компании и команды внутри них организованы таким образом, что затруднительно оценивать что-либо — будь то сложность проекта, его сроки, бюджет. И так же сложно осуществлять мониторинг и прогнозирование. Большинство умозаключений, которые можно сделать в ходе наблюдения за проектом, являются довольно хрупкими закономерностями, которые очень сильно зависят от слишком большого количества переменных. Более того, многие проекты или компании малы, так что вообще какие-либо закономерности и тренды выявлять опасно, т.к. для команды из пары тройки разработчиков в проекте на 3-4 месяца ошибка оценки можен переваливать за 200%, что никуда не годится. Я к тому, что всё настолько иднивидуально, что рецепт, успешно применяемый в условном IBM, скорее всего не сработает в фирме «Рога и Копыта» с персоналом 20 человек вместе с уборщицей.
Я не говорю, что этим не надо заниматься. Напротив: следует всегда держать руку на пульсе. Но следует больше пользоваться головой и руководствоваться здравым смыслом, нежели упражняться в склонении новомодных терминов. В данном случае Scrum ни причём совершенно.
Поддержу, пост не совсем даже про Scrum.
Про жонглирование — автор предлагает несколько рецептов. Понятно что их надо адаптировать к реальным условиям. Для этого в Scrum и есть «белые пятна», и он не является по этому методологией, а является просто фреймворком — фактически набором ценностей и ключевых практик, описывающих основной процесс (планирование, инкремент, итерации, ретроспективы).
Если говорить про оценки, то в целом, Scrum не очень-то приемлет оценки как таковые. Он про сокращение рисков, а не про планирование на 10 лет вперед. Что, кажется, имеет ограниченное применение.
Рецепты нужно пробовать. В системе которая находится в абсолютном покое, не может происходить положительных улучшений.
Ну и опять же, серебряной пули мы не найдем, и я с вами во многом согласен. В конце концов госпроекты и тендеры никто не отменял. Это под час явные попытки впихнуть невпихуемое, и ни один скрам здесь не поможет.
Про жонглирование — автор предлагает несколько рецептов. Понятно что их надо адаптировать к реальным условиям. Для этого в Scrum и есть «белые пятна», и он не является по этому методологией, а является просто фреймворком — фактически набором ценностей и ключевых практик, описывающих основной процесс (планирование, инкремент, итерации, ретроспективы).
Если говорить про оценки, то в целом, Scrum не очень-то приемлет оценки как таковые. Он про сокращение рисков, а не про планирование на 10 лет вперед. Что, кажется, имеет ограниченное применение.
Рецепты нужно пробовать. В системе которая находится в абсолютном покое, не может происходить положительных улучшений.
Ну и опять же, серебряной пули мы не найдем, и я с вами во многом согласен. В конце концов госпроекты и тендеры никто не отменял. Это под час явные попытки впихнуть невпихуемое, и ни один скрам здесь не поможет.
Про жонглирование — это не к вам и не к автору. Я всё-таки с вами не знаком, чтобы делать такие сильные утверждения. Я скорее про наблюдаемую тенденцию, между делом.
Набор практик — это хорошо, хотя именно это и пугает, потому что многие читают не «набор практик», а «всегда удачный и везде применимый набор практик». Но если кто-то утверждает, что эти практики хорошо применились в конкретной компании на конкретном проекте с конкретной командой, то прежде всего встаёт вопрос не в том, удачны практики или нет, а в сопоставлении вашего конкретного проекта с тем самым проектом, где эти практики удачно применились. А с этим как раз проблемы, потому что помимо каких-то субъективных параметров для сопоставления нужны прежде всего объективные параметры. Которые никто не знает как оценивать либо их просто крайне затруднительно оценить для конкретного проекта. Т.е., к примеру, вам привели в пример проект, в котором здорово применяются определённые практики, и параметры проекта вам выданы… в килограммах. Вы пытаете оценить свой проект на применимость этих практик и получаетете оценку… в метрах. Вот и думайте потом, как сопоставить эти килограммы с вашими метрами. Кто-то из авторов, возможно, приведёт вам эмпирически выведенный коэффициент для конвертации килограммов в метры, но этот коэффициент рассчитан по сотням компаний с командами в 30-100 человек. А у вас всего лишь 5 человек в команде. И вы применяете этот коэффициент. И справедливо получаете ошибку в 200%. И проект ваш разлетается в щепки.
Scrum вполне приемлет оценки. Другое дело, что не так часто авторы упоминают о такой необходимости, и читатель как бы подразумевает, что обойдётся безо всяких измерений. Измерить можно что угодно и измерять надо. Вопрос лишь в том, как это сделать. Для получения системы оценок в компании руководства и заказчики должны с пониманием относиться к этому. Потому что главный бонус, который можно получить на выхлопе — это стабильность, повторяемость результата. Но в подавляющем большинстве случаев людям не нужна какая-то повторяемость, стабильность, нужен лишь сиюминутный результат, а там хоть трава не расти. С новым проектом начнём с самого начала. И так по кругу. В результате редкий руководитель владеет такими знаниями и совсем редко такие знания оседают в базах знаний компаний.
Набор практик — это хорошо, хотя именно это и пугает, потому что многие читают не «набор практик», а «всегда удачный и везде применимый набор практик». Но если кто-то утверждает, что эти практики хорошо применились в конкретной компании на конкретном проекте с конкретной командой, то прежде всего встаёт вопрос не в том, удачны практики или нет, а в сопоставлении вашего конкретного проекта с тем самым проектом, где эти практики удачно применились. А с этим как раз проблемы, потому что помимо каких-то субъективных параметров для сопоставления нужны прежде всего объективные параметры. Которые никто не знает как оценивать либо их просто крайне затруднительно оценить для конкретного проекта. Т.е., к примеру, вам привели в пример проект, в котором здорово применяются определённые практики, и параметры проекта вам выданы… в килограммах. Вы пытаете оценить свой проект на применимость этих практик и получаетете оценку… в метрах. Вот и думайте потом, как сопоставить эти килограммы с вашими метрами. Кто-то из авторов, возможно, приведёт вам эмпирически выведенный коэффициент для конвертации килограммов в метры, но этот коэффициент рассчитан по сотням компаний с командами в 30-100 человек. А у вас всего лишь 5 человек в команде. И вы применяете этот коэффициент. И справедливо получаете ошибку в 200%. И проект ваш разлетается в щепки.
Scrum вполне приемлет оценки. Другое дело, что не так часто авторы упоминают о такой необходимости, и читатель как бы подразумевает, что обойдётся безо всяких измерений. Измерить можно что угодно и измерять надо. Вопрос лишь в том, как это сделать. Для получения системы оценок в компании руководства и заказчики должны с пониманием относиться к этому. Потому что главный бонус, который можно получить на выхлопе — это стабильность, повторяемость результата. Но в подавляющем большинстве случаев людям не нужна какая-то повторяемость, стабильность, нужен лишь сиюминутный результат, а там хоть трава не расти. С новым проектом начнём с самого начала. И так по кругу. В результате редкий руководитель владеет такими знаниями и совсем редко такие знания оседают в базах знаний компаний.
Некоторые тезисы мне непонятны:
>Подсчитывайте число дней в которые сборки упали в этом месяце. Поощряйте за месяцы без падений. Измеряйте время, пока неисправности остаются не устраненными.
Что страшного в падении сборки? Нафига нам тогда CI если мы боимся падений? Может еще премии за отсутствие багов выдавать?
>Измеряйте размер тестов. Тестовые методы должны быть от пять до двадцати строк кода. Общее количество тестового кода должно быть примерно равно количеству продуктового кода.
А это меня всегда забавляло в пуристах TTD подхода. Тестировать каждый чих. Писать тесты на код который скорее всего и до конца итерации не дотянет.
>Измеряйте размер функций и классов. Средняя функция должна иметь менее 10 строк кода. Функции длиннее 20 строк надо разбивать. Классы более 500 строк следует разбивать на два и более классов. Измеряйте корреляцию Брейтвэйта, она должна иметь значение более 2.
Для какого это языка? 10 строчек на руби или питоне это не 10 строчек на яве. Опять таки далеко не всегда это можно сделать. Какие-то сложные алгоритмы не всегда возможно разбить.
500 строчек на класс много? Может и много, а может вы уже в архитектурной стратосфере.
Как и все подобные статьи тут довольно много благих намерений, слепо следуя которым, можно зайти в неплохую задницу.
>Подсчитывайте число дней в которые сборки упали в этом месяце. Поощряйте за месяцы без падений. Измеряйте время, пока неисправности остаются не устраненными.
Что страшного в падении сборки? Нафига нам тогда CI если мы боимся падений? Может еще премии за отсутствие багов выдавать?
>Измеряйте размер тестов. Тестовые методы должны быть от пять до двадцати строк кода. Общее количество тестового кода должно быть примерно равно количеству продуктового кода.
А это меня всегда забавляло в пуристах TTD подхода. Тестировать каждый чих. Писать тесты на код который скорее всего и до конца итерации не дотянет.
>Измеряйте размер функций и классов. Средняя функция должна иметь менее 10 строк кода. Функции длиннее 20 строк надо разбивать. Классы более 500 строк следует разбивать на два и более классов. Измеряйте корреляцию Брейтвэйта, она должна иметь значение более 2.
Для какого это языка? 10 строчек на руби или питоне это не 10 строчек на яве. Опять таки далеко не всегда это можно сделать. Какие-то сложные алгоритмы не всегда возможно разбить.
500 строчек на класс много? Может и много, а может вы уже в архитектурной стратосфере.
Как и все подобные статьи тут довольно много благих намерений, слепо следуя которым, можно зайти в неплохую задницу.
>Измеряйте размер функций и классов. Средняя функция должна иметь менее 10 строк кода. Функции длиннее 20 строк надо разбивать. Классы более 500 строк следует разбивать на два и более классов. Измеряйте корреляцию Брейтвэйта, она должна иметь значение более 2.
Видел-видел… Код финкций порезан на более мелкие функции без какой-либо логики. Вместо одного, большого, но логичного класса, куча каких-то обрубков, ибо надо же быстро achieve points, да ещё чтоб метрикам удовлетворить. А потом нужно вносить изменения — в каждый из обрубков отдельно.
Видел-видел… Код финкций порезан на более мелкие функции без какой-либо логики. Вместо одного, большого, но логичного класса, куча каких-то обрубков, ибо надо же быстро achieve points, да ещё чтоб метрикам удовлетворить. А потом нужно вносить изменения — в каждый из обрубков отдельно.
>>Что страшного в падении сборки?
Там важна скорее следующая фраза: измеряйте время, за которое устраняется фэйл.
Естественно же, если вы устраняете фэйл дольше, значит этот фэйл больше. Если этот фэйл такой большой, может быть проблемы с архитектурой?..
>>Измеряйте размер тестов.
Это про то, чтобы сразу детектировать вермишель и blob'ы в тестах. тот же PMD с этим справляется на ура. Все остальное — добавляйте по вкусу. Не нравится часто переписывать тесты — а дебажить часами нравится? Всё относительно и быть категоричным глупо.
>>Для какого это языка?
Такой же вопрос. Видимо это про Java, т.к. автор упоминает тулы для Java.
Очевидно что 10 строчек на Питоне это достаточно толсто в сравнении с 10 строчками на Java.
>>500 строчек на класс много?
Да, в Java, в AS3, и даже местами в C++ это много. Это просто необозримый код, т.к. нужно листать очень много экранов. В конце концов, ничто не запрещает делать декомпозицию класса до той степени, до которой с ним удобно работать.
Я бы конечно поправил и сказал, что 1000 строк это много. Да, 1000 строк это много.
>>Как и все подобные статьи тут довольно много благих намерений, слепо следуя которым, можно зайти в неплохую задницу.
Да. И я повторюсь, что считаю, что их следует попробовать и проанализировать полученный результат. И принимать осмысленно.
Там важна скорее следующая фраза: измеряйте время, за которое устраняется фэйл.
Естественно же, если вы устраняете фэйл дольше, значит этот фэйл больше. Если этот фэйл такой большой, может быть проблемы с архитектурой?..
>>Измеряйте размер тестов.
Это про то, чтобы сразу детектировать вермишель и blob'ы в тестах. тот же PMD с этим справляется на ура. Все остальное — добавляйте по вкусу. Не нравится часто переписывать тесты — а дебажить часами нравится? Всё относительно и быть категоричным глупо.
>>Для какого это языка?
Такой же вопрос. Видимо это про Java, т.к. автор упоминает тулы для Java.
Очевидно что 10 строчек на Питоне это достаточно толсто в сравнении с 10 строчками на Java.
>>500 строчек на класс много?
Да, в Java, в AS3, и даже местами в C++ это много. Это просто необозримый код, т.к. нужно листать очень много экранов. В конце концов, ничто не запрещает делать декомпозицию класса до той степени, до которой с ним удобно работать.
Я бы конечно поправил и сказал, что 1000 строк это много. Да, 1000 строк это много.
>>Как и все подобные статьи тут довольно много благих намерений, слепо следуя которым, можно зайти в неплохую задницу.
Да. И я повторюсь, что считаю, что их следует попробовать и проанализировать полученный результат. И принимать осмысленно.
Для какого это языка?В общем, для любого; принцип — про физическую обозримость, а не про функциональность. Метод должен охватываться взглядом и влезать в один экран. Если на каких-то языках существенная логика в экран не влазит — значит, горе таким языкам, только и всего.
В реальности всё ещё интереснее — mess уже создан тремя поколениями ушедших разработчиков и двумя поколениями очень нервных менеджеров (коих в два раза больше чем технарей и каждый со своими идеями). А теперь надо как-то этот mess заставлять работать, а он ломается тут, там, и ещё в десяти местах, а про остальные двадцать мы ещё просто и не знаем, узнаем потом, в продакшене. Ну и как тут TDD с pair programming применять? Чего и чем мерить?
Здесь не мерить надо :) Здесь надо переписывать пока никто не видит.
Речь то о том, что у вас проект уже н-ое время длиться и у вас все ок, но велосити падает. А тут у вас до велосити еще дорасти.
Переписывать кусками, покрывать тестами что можно, распутывать вермишель. Если кодбаза еще и на разных языках (часть на С, часть на Perl, часть на еще чем-то), то только переписывать.
Речь то о том, что у вас проект уже н-ое время длиться и у вас все ок, но велосити падает. А тут у вас до велосити еще дорасти.
Переписывать кусками, покрывать тестами что можно, распутывать вермишель. Если кодбаза еще и на разных языках (часть на С, часть на Perl, часть на еще чем-то), то только переписывать.
Подозреваю, что на уровне программистов такая проблема нерешаема
Не могли бы вы развернутее пояснить свою точку зрения?
Переписывать проект, пока никто не видит, не выйдет, если менеджеры, приведшие проект к такому состоянию, все ещё у руля. Обычно, выделение времени на переписывание (которое в любом случае понадобится рано или поздно, даже если писать из-под полы) идет вразрез с текущими проблемами, которые нужно решать здесь и сейчас.
Вести две ветки проекта? Но на это опять нужны ресурсы. Но ведь стоимость поддержки первой ветки будет расти со временем…
> Но ведь стоимость поддержки первой ветки будет расти со временем
Интересно, что по опыту работы попыток одновременно вести две версии продукта (одна — допиливание оригинала, вторая — запиливание нового приложения) было как минимум две, в одной компании в итоге от второй ветки отказались (первая всегда была актуальнее второй), а в другой — наоборот в итоге отбросили первую ветку и сконцентрировались на второй.
Но во втором варианте необходимость переписывания была понятна руководству, а в первом — вряд ли )
Интересно, что по опыту работы попыток одновременно вести две версии продукта (одна — допиливание оригинала, вторая — запиливание нового приложения) было как минимум две, в одной компании в итоге от второй ветки отказались (первая всегда была актуальнее второй), а в другой — наоборот в итоге отбросили первую ветку и сконцентрировались на второй.
Но во втором варианте необходимость переписывания была понятна руководству, а в первом — вряд ли )
А про разрезание функций — XP и TDD не отменяют необходимость использования головы при написании кода.
Не очень понравилась статья.
Дело вот в чем, если у вас команда начинает «костыльничать» на старте, она просто не понимает, что выкашивать эти костыли придётся ей через некоторое время. И тут как-раз встаёт вопрос к коучу, который эту команду ведёт: «А объяснил ли он это команде?».
Второе, в статье придумывается модель премирования команды по численным показателям — это очень опасная тема, и тут как раз можно угодить в ловушку, которой является основная тема статьи. Команда просто начинает работать не на результат а на показатель — и в этом ключевая проблема.
Как выход из положения я бы не стал рассматривать TDD. Начать скорее надо с Code Review и Gated Commits c точки зрения инженерии, а с точки зрения работы с командой — надо ставить не тактические а стратегические цели, надо сделать понимание у команды всего пути получения готового продукта и очень осторожно работать с численными показателями.
Дело вот в чем, если у вас команда начинает «костыльничать» на старте, она просто не понимает, что выкашивать эти костыли придётся ей через некоторое время. И тут как-раз встаёт вопрос к коучу, который эту команду ведёт: «А объяснил ли он это команде?».
Второе, в статье придумывается модель премирования команды по численным показателям — это очень опасная тема, и тут как раз можно угодить в ловушку, которой является основная тема статьи. Команда просто начинает работать не на результат а на показатель — и в этом ключевая проблема.
Как выход из положения я бы не стал рассматривать TDD. Начать скорее надо с Code Review и Gated Commits c точки зрения инженерии, а с точки зрения работы с командой — надо ставить не тактические а стратегические цели, надо сделать понимание у команды всего пути получения готового продукта и очень осторожно работать с численными показателями.
Ещё хочу себя дополнить
Вообще, проблема работы по численным показателям стимулирующим тактические действия — это не проблема Scrum или IT-отрасли. Это вообще проблема менеджмента в глобальном масштабе. «Приведи аналогию» — скажете вы. Ок, вот аналогия:
Есть компания которая вышла на IPO, там нанимают манагера и в качестве мотиватора к достижению дают ему опцион (преимущество покупки акций по определенной цене). Манагер начинает действовать в целях повышения курса акций (работать на свой опцион) зачастую ломая работу компании и нанося её непоправимый вред. Через некоторое время манагер поднимает курс, реализует опцион и сваливает. А компания оказывается в предбанкротном состоянии.
Вообще, проблема работы по численным показателям стимулирующим тактические действия — это не проблема Scrum или IT-отрасли. Это вообще проблема менеджмента в глобальном масштабе. «Приведи аналогию» — скажете вы. Ок, вот аналогия:
Есть компания которая вышла на IPO, там нанимают манагера и в качестве мотиватора к достижению дают ему опцион (преимущество покупки акций по определенной цене). Манагер начинает действовать в целях повышения курса акций (работать на свой опцион) зачастую ломая работу компании и нанося её непоправимый вред. Через некоторое время манагер поднимает курс, реализует опцион и сваливает. А компания оказывается в предбанкротном состоянии.
А компания оказывается в предбанкротном состоянии.Вопрос — а не было ли именно это настоящей целью?
И ещё дополню, когда вводите метрику, задайте себе вопрос, а можно ли это напрямую спроецировать на ROI. Нельзя собирать метрику ради метрики.
Измеряйте Цикломатическую сложность. Функции, которые очень сложны (например, cc > 6 или близко к этому) должны быть подвергнуты рефакторингу. Используйте средства наподобие Crap4J, чтобы определить методы и функции, нарушающие это правило и имеющие наименьшее покрытие тестами.
Подсчитывайте количество комитов в день. Это число должно быть больше, чем число разработчиков в команде. Поощряйте частые комиты.
Измеряйте размер тестов. Тестовые методы должны быть от пять до двадцати строк кода. Общее количество тестового кода должно быть примерно равно количеству продуктового кода.— откуда такая средняя температура по больнице? как количество строк вообще влияет на качество тестов?
Измеряйте скорость тестов. Тесты должны отрабатывать быстро; минуты, а не часы. Поощряйте за быстрые тесты.не согласен, тест должен быть качественным. При нормальном CI с Gated Commit надо просто делать набор быстрых тестов для проверки коммитов, а полные жирные тесты гонять по ночам. А уж судить о том хорошо тест или нет по скорости его работы — это неправильно.
Измеряйте хрупкость тестов (Прим. пер.: test breakage). Тесты должны быть разработаны таким образом, чтобы изменения в продуктовом коде приводили к небольшим поломкам тестов. Если большая часть тестов падает, когда изменяется продуктовый код, то тесты требуют рефакторинга (Прим. пер. test design needs improving).изменеия в продуктовом коде не должны ломать тесты, на то они и тесты чтобы делать автоматический регресс. Если делаются изменения логики обработки, то это скорее сработавший архитектурный риск. Считаю что трата времени на продумывание менее хрупких тестов — это потеря. Хотя может у кого есть факт из реальной жизни, когда на правку тестов выходило больше времени, чем на продумывание менее хрупких?
Измеряйте Цикломатическую сложность. Функции, которые очень сложны (например, cc > 6 или близко к этому) должны быть подвергнуты рефакторингу. Используйте средства наподобие Crap4J, чтобы определить методы и функции, нарушающие это правило и имеющие наименьшее покрытие тестами.
Измеряйте размер функций и классов. Средняя функция должна иметь менее 10 строк кода. Функции длиннее 20 строк надо разбивать. Классы более 500 строк следует разбивать на два и более классов. Измеряйте корреляцию Брейтвэйта, она должна иметь значение более 2.это практика XP по созданию чистого кода. Тут скорее надо смотреть на читаемость а не на количество строк
Измеряйте метрики зависимостей. Убедитесь, что нет циклических зависимостей. Убеждайтесь, что поток зависимостей идет в направлении абстрагирования, в соответствии с принципом обращения зависимостей и принципом стабильных абстракций (Прим. Принцип стабильных абстракций: пакеты, которые максимально неизменчивы, должны быть максимально абстрактными. Изменчивые пакеты должны быть конкретными. Абстрагированность пакета должна быть пропорциональна его изменчивости.). главное в этом не увязнуть. Нам нужен продукт а не офигенно абстрагированные пакеты.Подсчитывайте количество комитов в день. Это число должно быть больше, чем число разработчиков в команде. Поощряйте частые комиты.
Подсчитывайте число дней в которые сборки упали в этом месяце. Поощряйте за месяцы без падений. Измеряйте время, пока неисправности остаются неустраненными.вперёд изучать 6 Sigma, метрика вообще ниочем.
Измеряйте «завершенность», запуская тесты на системе непрерывной интеграции и следите за историями тестирования, которые прошли или упали. Используйте это как основу показателя производительности и прогресса команды. Внедрите правило, что user story не считается законченной, пока соответствующая история тестирования не пройдет тест, и никогда не позволяйте ломаться тестам, которые уже прошли.а вы принимаете стори с нерабочими тестами? или сломанным регрессом? Это надо не вводить правило. Оно должно быть изначально
Про тесты я уже писал: здесь просто говориться о том, чтобы раньше всего выявлялись самые простые для идентификации запахи — blob, хрупкие тесты, медленный тест, эхо в горах.
Это очень полезно, но требует очень чуткой настройки. Если использовать тот же PMD с дефолтными настройками, он выводит кучу мусора в отчете.
Если хрупкие тесты не так страшны, т.к. их быстро можно поднять, то эхо в горах с ростом проекта становится проблемой, т.к. тесты уже становится невозможно использовать как средство для локализации ошибки (снова идем в дебаг). То же и про blob — он усложняет понимание чужого кода. Медленный тест приводит к тому что разработчики просто реже пускают весь тестовый набор, что неприятно аукается.
Про цикломатическую сложность и количество строк — всегда было пох, но это тревожный звонок что метод или класс сложноват и лучше лишний раз по нему провести кодревью.
Это очень полезно, но требует очень чуткой настройки. Если использовать тот же PMD с дефолтными настройками, он выводит кучу мусора в отчете.
Если хрупкие тесты не так страшны, т.к. их быстро можно поднять, то эхо в горах с ростом проекта становится проблемой, т.к. тесты уже становится невозможно использовать как средство для локализации ошибки (снова идем в дебаг). То же и про blob — он усложняет понимание чужого кода. Медленный тест приводит к тому что разработчики просто реже пускают весь тестовый набор, что неприятно аукается.
Про цикломатическую сложность и количество строк — всегда было пох, но это тревожный звонок что метод или класс сложноват и лучше лишний раз по нему провести кодревью.
Так не бывает. Условия меняются и проект должен эволюционировать с готовыми релизами и обратной связью от внедрения. Сначала быстро, потому что вы наепываете себя, думая, что знаете БЕЗ ОПЫТА, какой система должна быть. А опыт = мысли, то есть на 80% хрень, минус реальность.
А после накопления реального опыта со знанием сферы проект можно и нужно рефакторить.
Работает не везде, но в вебе на 99 процентов.
А после накопления реального опыта со знанием сферы проект можно и нужно рефакторить.
Работает не везде, но в вебе на 99 процентов.
«Паша, нужно жить так, будто сегодняшний день — последний день твоей жизни!» Да-да, это очень умно, думал я. Я даже пытался следовать этой доктрине. Только потом я понял, что такой образ жизни приводил к катастрофической, стопроцентной потере времени. Этот способ общеизвестен. Он называется — суета. Нет, надо жить так, будто у тебя впереди вечность. Надо затевать великие, долговременные дела.
(с) Ю.Визбор, Завтрак с видом на Эльбрус, 1983
(с) Ю.Визбор, Завтрак с видом на Эльбрус, 1983
Спасибо, выучил новое слово «crap4j».
Может быть не совсем в тему, но хотелось бы сказать, что, по моему опыту, НИОКР также убивает (или сильно вредит) технике управления временем pomodoro
Как бороться с проблемой оценки того, что трудно оценить так и не понял :(
Планирование от этого сильно страдает, но если это story в scrum, то алгоритм предложенный pimenaus стоит попробовать. Мне понравился.
А вот, что делать с pomodoro — не знаю. Такие задачи, видимо, вообще не лажаться на подобные техники (очень полезные, кстати).
p.s. arrgh! Не туда ответил, прошу прощения.
Как бороться с проблемой оценки того, что трудно оценить так и не понял :(
Планирование от этого сильно страдает, но если это story в scrum, то алгоритм предложенный pimenaus стоит попробовать. Мне понравился.
А вот, что делать с pomodoro — не знаю. Такие задачи, видимо, вообще не лажаться на подобные техники (очень полезные, кстати).
p.s. arrgh! Не туда ответил, прошу прощения.
Спасибо, отличная статья, в отличие от большинства на тему scrum'а. Очень полезно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Остров, о котором забыл Scrum