Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 73
Программист, который может держать код в голове и отличается скорострельностью — отличный профессионал.
В некоторых областях такой будет куда приятнее, чем человек, который тривиальную функцию будет неделю вылизывать с юнит-тестами и функциональным тестрованием.
Говорю без шуток, ибо стоимость сопровождения определяется тем, сколько код сопровождать. Бывает код, который вообще не сопровождается (написан, работает и ладно). В этих условиях мы имеем минимальную стоимость разработки при максимальной скорости.
Разумеется, это не очень хороший подход для постоянно развиваемого кода, но есть масса областей, где надо «написать и забыть». И там такой подход даст большую эффективность, чем любые системы управления хаосом.
В некоторых областях такой будет куда приятнее, чем человек, который тривиальную функцию будет неделю вылизывать с юнит-тестами и функциональным тестрованием.
Говорю без шуток, ибо стоимость сопровождения определяется тем, сколько код сопровождать. Бывает код, который вообще не сопровождается (написан, работает и ладно). В этих условиях мы имеем минимальную стоимость разработки при максимальной скорости.
Разумеется, это не очень хороший подход для постоянно развиваемого кода, но есть масса областей, где надо «написать и забыть». И там такой подход даст большую эффективность, чем любые системы управления хаосом.
Я очень очень надеюсь на отрицательный ответ — подход «написать и забыть» надеюсь не практикуется в Селектеле? :)
В том числе практикуется. Например, на позапрошлом спринте была задача — написать прототип утилиты для манипуляции объектом, который бы проверял правильность реализации всех остальных компонент.
Я на момент планирования на 100% знал, что этот код не будет обслуживаться. Его задача — увидеть, как оно всё работает, найти неочевидные баги в соглашениях между компонентами и т.д.
Нафига мне там мега-девелопмент, когда его надо просто пойти и накодить?
Более того, я вот только что аналогичным образом накодил себе шелловый «однострочник» примерно в 4 кб размером, который делает головоломную выборку из нескольких баз, обрабатывает их и выдаёт на выходе умные циферки, над которыми я буду думать.
Аналогично — код есть, сопровождения нет.
Одной из профессиональных деформаций хороших программистов является мысль, что всё, что они пишут, является нетленкой. Это мотивирует делать хорошо, однако, замедляет процесс. Иногда это не нетленка, а инструмент однократного применения. И в этом случае быстрее похерить любые методологии разработки ПО и просто взять-и-написать.
Заметим, это никаким образом не относится к тому коду, который мы сопровождаем. Там у нас во-первых двухуровневое code review, во вторых каждый epic имеет подробную документацию с мотивационной частью, шагами реализации и описанием вносимых изменений, причём написанный до того, как расписаны все issue.
Но нужно понимать, что если в центральный сервер биллинга мы готовы инвестировать scrum, code review, рефакторинг технического долга и т.д., то это вовсе не значит, что подобный подход должен применяться всюду.
Я на момент планирования на 100% знал, что этот код не будет обслуживаться. Его задача — увидеть, как оно всё работает, найти неочевидные баги в соглашениях между компонентами и т.д.
Нафига мне там мега-девелопмент, когда его надо просто пойти и накодить?
Более того, я вот только что аналогичным образом накодил себе шелловый «однострочник» примерно в 4 кб размером, который делает головоломную выборку из нескольких баз, обрабатывает их и выдаёт на выходе умные циферки, над которыми я буду думать.
Аналогично — код есть, сопровождения нет.
Одной из профессиональных деформаций хороших программистов является мысль, что всё, что они пишут, является нетленкой. Это мотивирует делать хорошо, однако, замедляет процесс. Иногда это не нетленка, а инструмент однократного применения. И в этом случае быстрее похерить любые методологии разработки ПО и просто взять-и-написать.
Заметим, это никаким образом не относится к тому коду, который мы сопровождаем. Там у нас во-первых двухуровневое code review, во вторых каждый epic имеет подробную документацию с мотивационной частью, шагами реализации и описанием вносимых изменений, причём написанный до того, как расписаны все issue.
Но нужно понимать, что если в центральный сервер биллинга мы готовы инвестировать scrum, code review, рефакторинг технического долга и т.д., то это вовсе не значит, что подобный подход должен применяться всюду.
Мы практикуем решение таких задач в отдельных бранчах с указанием, что этот код был «просто написан», чтобы потом к нему не было доверия на том же уровне как к остальному коду. Тогда для разовых задач или прототипов это вполне приемлемый подход. Не так давно обсуждали это в другой ветке.
Вам не кажется, что
который может держать код в головеи
написать и забытьнемного противоречивые вещи?
>>такой подход даст большую эффективность
Совершенно верно, именно по эффективности и стоит выбирать методику.
Однако статья пытается донести мысль, что на долгосрочной перспективе (если она, конечно, интересует бизнес), подобная работа «налячкать и забыть» может оказаться серьёзной подставой.
Короче, нет серебрянной пули, надо выбирать по обстоятельствам. Иногда говнокодинг — это то, что нужно, но не так часто, как это пытаются преподнести
Совершенно верно, именно по эффективности и стоит выбирать методику.
Однако статья пытается донести мысль, что на долгосрочной перспективе (если она, конечно, интересует бизнес), подобная работа «налячкать и забыть» может оказаться серьёзной подставой.
Короче, нет серебрянной пули, надо выбирать по обстоятельствам. Иногда говнокодинг — это то, что нужно, но не так часто, как это пытаются преподнести
Вы много видели апологетов говнокодинга? Большинство либо молчит, либо говорит «ура» юнит-тестам и прочим играм. При этом многие из тех, кто согласен, продолжают говнокодить.
Видел много, да.
При этом отдаю себе отчёт, что «другого народа у меня для вас нет» — в смысле, предпочитаю максимально полезно использовать то, что у меня есть. Как и вы, думаю
При этом отдаю себе отчёт, что «другого народа у меня для вас нет» — в смысле, предпочитаю максимально полезно использовать то, что у меня есть. Как и вы, думаю
Апологетов или тихих сторонников? Апологетов (которые бы это в виде стратегии разработки объявляли вслух) я не видел.
А вот ползуче-неосозанное — это да, часто.
А вот ползуче-неосозанное — это да, часто.
Увы, да, это очень часто. Code review спасает, хотя есть и свои трудности.
Про ползуче-неосознанно есть ещё момент в том, что на масштабах команды 20 и больше начинаешь воспринимать разработчиков как абстрактно-средних… Даже если в команде есть один-другой с перегибами в обе стороны, это сильно дела не меняет (хотя и улучшает). Начинается управление разработкой по закону больших чисел. А абстрактный разработчик пишет далеко не самый лучший код
Про ползуче-неосознанно есть ещё момент в том, что на масштабах команды 20 и больше начинаешь воспринимать разработчиков как абстрактно-средних… Даже если в команде есть один-другой с перегибами в обе стороны, это сильно дела не меняет (хотя и улучшает). Начинается управление разработкой по закону больших чисел. А абстрактный разработчик пишет далеко не самый лучший код
Лучше стабильно средний, чем эпизодически хороший. Честно, что будет в команде из 20 человек — не знаю, это очень много. Тут явно нужны доп. уровни структурирования, ибо если каждый человек за неделю делает 10 issue с средним размером 2 sp, то это 400 issue в неделю, столько один человек написать и организовать не сможет.
Я не видел ни одной задачи в стиле «нам нужно гавнокод». Ну разве что — если Вы хотите создать тестовое задание для программиста (как выяснилось в ходе обсуждения одной из статьи на хабре — и это спорно). Так может быть всё же гавнокод — НИКОГДА не нужен? Может быть хватит оправдывать себя «я пишу быстро — значит плохо»? Посмотрите на спортсменов — быстрые движения — не значит плохие.
Не могу понять, где я написал про оправдывать.
А я не видел ни одной задачи «надо написать JIT-компилятор» или «надо сделать рефакторинг». Заказчику не нужна дрель, ему нужны дырки. При этом как вы их сделаете — его не сильно волнует. Если дырок надо немного, и на этом ваше сотрудничество прекращается — то можно и коловоротом накрутить.
А я не видел ни одной задачи «надо написать JIT-компилятор» или «надо сделать рефакторинг». Заказчику не нужна дрель, ему нужны дырки. При этом как вы их сделаете — его не сильно волнует. Если дырок надо немного, и на этом ваше сотрудничество прекращается — то можно и коловоротом накрутить.
>>Иногда говнокодинг — это то, что нужно
Не ваши ли это слова?
Вы правильно подметили — Заказчику нужен рабочий продукт, а не код. Так вот речь о том, что можно писать хороший код, даже если нужно что-то сделать быстро и один раз. Потому что это быстро. Потому что все паттерны, архитектурные изыски, стандарты кодинга и так далее придуманны с одной единственной целью — писать код более быстро. То, что их применяют не по делу — уже другой разговор.
Когда Вы даёте себе индульгенцию на гавнокод (это быстрый фикс к релизу, это просто прототип, надо сделать быстро чтоб показать заказчику, потом переделаю) — Вы понижаете свой стиль. Знаете, в единоборствах одно из главных правил — выполнять техники правильно. Можно медленно. Но правильно. Потому что привыкнув делать неправильно (обычно это случается, когда пытаешься делать быстро) — потом очень тяжело переучиться. И результаты получаются плачевными.
И последнее — в каждом большом проекте, где я работал, я нахожу огромное колличество меток ToDo — значит кто-то понимал, что код плох, но всё равно его оставил…
Не ваши ли это слова?
Вы правильно подметили — Заказчику нужен рабочий продукт, а не код. Так вот речь о том, что можно писать хороший код, даже если нужно что-то сделать быстро и один раз. Потому что это быстро. Потому что все паттерны, архитектурные изыски, стандарты кодинга и так далее придуманны с одной единственной целью — писать код более быстро. То, что их применяют не по делу — уже другой разговор.
Когда Вы даёте себе индульгенцию на гавнокод (это быстрый фикс к релизу, это просто прототип, надо сделать быстро чтоб показать заказчику, потом переделаю) — Вы понижаете свой стиль. Знаете, в единоборствах одно из главных правил — выполнять техники правильно. Можно медленно. Но правильно. Потому что привыкнув делать неправильно (обычно это случается, когда пытаешься делать быстро) — потом очень тяжело переучиться. И результаты получаются плачевными.
И последнее — в каждом большом проекте, где я работал, я нахожу огромное колличество меток ToDo — значит кто-то понимал, что код плох, но всё равно его оставил…
Золотые слова.
Вы тут везде упоминаете «хороший код», вкладывая некоторое понимание. Я же в своих комментариях говорю, что код должен быть «достаточно хорошим», а не просто «хорошим». Потому что под «хорошим» разные люди понимают разное, и тут главное — не перегибать в обе стороны.
Да вы это и так понимаете
Вы тут везде упоминаете «хороший код», вкладывая некоторое понимание. Я же в своих комментариях говорю, что код должен быть «достаточно хорошим», а не просто «хорошим». Потому что под «хорошим» разные люди понимают разное, и тут главное — не перегибать в обе стороны.
Да вы это и так понимаете
>> все паттерны, архитектурные изыски, стандарты кодинга и так далее придуманны с одной единственной целью — писать код более быстро
Знаете, я не раз и не два встречался с ситуацией на проекте, где они _не_ помогали писать быстрее. Зачем их использовали — дань традициям, сила авторитета, чтобы было, архитектурная мастурбация, перфекционизм — это другой вопрос.
Если вам юнит-тесты не помогают повысить эффективность в оговоренном периоде — не надо их использовать.
Я только два тула знаю, которые следует использовать всегда, независимо от периода и эффективности — код-ревью и continuos integration+грамотный сорс-контрол.
Для всего остального можно найти случаи, когда их использование приносит больше вреда, чем пользы. Если наступает такая ситуация — то вред проекту приносить не надо, надо оценить и сделать верное решение к пользе проекта.
И я надеюсь, никто эти слова не воспримет как указание отказаться от своих полезных практик :)
Знаете, я не раз и не два встречался с ситуацией на проекте, где они _не_ помогали писать быстрее. Зачем их использовали — дань традициям, сила авторитета, чтобы было, архитектурная мастурбация, перфекционизм — это другой вопрос.
Если вам юнит-тесты не помогают повысить эффективность в оговоренном периоде — не надо их использовать.
Я только два тула знаю, которые следует использовать всегда, независимо от периода и эффективности — код-ревью и continuos integration+грамотный сорс-контрол.
Для всего остального можно найти случаи, когда их использование приносит больше вреда, чем пользы. Если наступает такая ситуация — то вред проекту приносить не надо, надо оценить и сделать верное решение к пользе проекта.
И я надеюсь, никто эти слова не воспримет как указание отказаться от своих полезных практик :)
>>Решения на будущее — архитектурные решения, которые принимаются на проекте, должны быть как можно больше адаптированы к изменениям. Нужно полностью планировать, какой компонент каким функционалом может обладать в будущем. Например, если это календарь (см. выше), то нужно расширить ядро таким образом, чтобы «в один клик» изменить формат вывода с 10-тичной на любую другую систему счисления, а также сменить грегорианский календарь на календарь в произвольной форме, описывающийся структурой в XML-файле, для которого также следует написать специальный парсер, который также следует адаптировать к генерации произвольных форматов XML не только для календарей, но и рецептов, вдруг у вас на сайте появятся рецепты?..
Я думаю отсюда все проблемы растут. Очень часто, начинают делать проект и:
— А что мы будем делать когда у нас будет 1М пользователей в день?! (пока ент ни одного)
— А если мы переползём на Oracle?
— Систему лучше изначально делать распределённой! (ни одного пользователя по прежнему нет)
— Нам надо так, что сегодня у нас одна концепция построяния каталога — а завтра мы ррраз, и поменяли всё (ни товаров, ни пользователей, ни поставщиков и в помине ещё нет)
Я думаю отсюда все проблемы растут. Очень часто, начинают делать проект и:
— А что мы будем делать когда у нас будет 1М пользователей в день?! (пока ент ни одного)
— А если мы переползём на Oracle?
— Систему лучше изначально делать распределённой! (ни одного пользователя по прежнему нет)
— Нам надо так, что сегодня у нас одна концепция построяния каталога — а завтра мы ррраз, и поменяли всё (ни товаров, ни пользователей, ни поставщиков и в помине ещё нет)
CI без фунционального тестирования — бомба замедленного действия. И когда-нибудь она взорвётся.
Я не могу оправдывать «себя», потому что я не программист. (И да, я знаю, что я пишу очень плохо, потому я предпочитаю писать очень мало и не лезу в крупные проекты). Я работаю lead'ом (он же менеджер проекта, он же product owner). То есть я о программистах рассуждаю по стороны, имея возможность отключиться от личного «я крутой программист» или «тут всё надо переписать во имя великой справедливости».
Так вот, я точно знаю, что у меня есть моменты, когда мне нужен говнокод. Который just do it. В конкретных условиях с конкретным уровнем сложности входных данных и т.д. И если вместо говнокода мне выдают DSL с красивой моделью, юнит-тестами и т.д. — я ругаюсь, ибо время потратили зря.
А бывает наоборот. И тогда я ругаюсь на говнокод. Точнее, на сам код я практически не смотрю, это разруливается code review, а я поддерживаю недовольных некрасивостью написанного.
Так вот, я точно знаю, что у меня есть моменты, когда мне нужен говнокод. Который just do it. В конкретных условиях с конкретным уровнем сложности входных данных и т.д. И если вместо говнокода мне выдают DSL с красивой моделью, юнит-тестами и т.д. — я ругаюсь, ибо время потратили зря.
А бывает наоборот. И тогда я ругаюсь на говнокод. Точнее, на сам код я практически не смотрю, это разруливается code review, а я поддерживаю недовольных некрасивостью написанного.
Скажите, если Вы не программист — то как Вы можете судить, что DSL с красивой моделью, юнит-тестами и т.д. — лишние?
Знаете, обычно принято как то обговаривать предварительно решение задачи. И если программисты поняли задание как требующее продолжительного моделирование — очевидно руководитель плохо обьяснил.
У руководителей есть одна плохая болезнь — они считают, что большинство архитектурных изысков — это причуды программистов. «Не парь мозги, просто СДЕЛАЙ чтоб работало». Поэтому, если Вы не разбераетесь в программировании — поставте одного из хороших разработчиков тех. лидом, и позвольте ему решать, какой код хорош в данном случае, а какой — нет. Программисты ОЧЕНЬ не любят слушать упрёки от людей, которые не разбераются в программировании.
Знаете, обычно принято как то обговаривать предварительно решение задачи. И если программисты поняли задание как требующее продолжительного моделирование — очевидно руководитель плохо обьяснил.
У руководителей есть одна плохая болезнь — они считают, что большинство архитектурных изысков — это причуды программистов. «Не парь мозги, просто СДЕЛАЙ чтоб работало». Поэтому, если Вы не разбераетесь в программировании — поставте одного из хороших разработчиков тех. лидом, и позвольте ему решать, какой код хорош в данном случае, а какой — нет. Программисты ОЧЕНЬ не любят слушать упрёки от людей, которые не разбераются в программировании.
Все-таки «разбираетесь» и «разбираются»…
>> ни считают, что большинство архитектурных изысков — это причуды программистов.
Добавлю свои 5 копеек. Вы тут почему-то полагаете, что программисты работают в своё удовольствие. Нет, это не так. Не в своё удовольствие, и не для таких же гиков-программистов, как они, а для свободных людей.
Программисты не высшая каста. Программы не самоценны, не надо делать программу, если ей никто не пользуется. Программисты это обслуга — такие же, как официант, дворник, или там сапожник.
И как у любой обслуги, у них есть мера эффективности.
А вот как им их работу делать внутри — это их собственное дело. Я не говорю, как дворнику держать лопату; но если один держит её так, что двор убирается в 10 раз медленнее, чем мог бы, а объясняет это тем, что так написано в книге «Паттерны уборки двора», а второй уже который день договаривается о выделении трактора, чтобы почистить сразу всё много, это негодные дворники
Добавлю свои 5 копеек. Вы тут почему-то полагаете, что программисты работают в своё удовольствие. Нет, это не так. Не в своё удовольствие, и не для таких же гиков-программистов, как они, а для свободных людей.
Программисты не высшая каста. Программы не самоценны, не надо делать программу, если ей никто не пользуется. Программисты это обслуга — такие же, как официант, дворник, или там сапожник.
И как у любой обслуги, у них есть мера эффективности.
А вот как им их работу делать внутри — это их собственное дело. Я не говорю, как дворнику держать лопату; но если один держит её так, что двор убирается в 10 раз медленнее, чем мог бы, а объясняет это тем, что так написано в книге «Паттерны уборки двора», а второй уже который день договаривается о выделении трактора, чтобы почистить сразу всё много, это негодные дворники
Не стоит привносить мерки индустриальной эпохи в постиндустриальную.
Программисты — не низшая каста, и не обслуга. Так же как не являются «обслугой» режисёры и актёры в фильмах, так же как не являются «обслугой» врачи.
Степень влияния человека на внутреннее качество кода не стоит недооценивать. peer review — лучшая сила в медицине, науке и программировании. При этом решаются бизнес-задачи, но превращение программиста в кодера режима офисного планктона лишает компанию второго из ресурсов, которые предоставляет программист за свою зарплату.
Ресурсов два: время и энтузиазм.
И scrum решает проблему времени. А вот вопрос энтузиазма решает атмосфера проекта и возможность самовыражения.
Можно отнять возможность самовыражения, но в этом случае компания просто заплатит больше денег за меньшее. Потому что «охота пуще неволи» и влияет очень сильно на качественные (в смысле «переход количества в качество») характеристики реализуемого.
Программисты — не низшая каста, и не обслуга. Так же как не являются «обслугой» режисёры и актёры в фильмах, так же как не являются «обслугой» врачи.
Степень влияния человека на внутреннее качество кода не стоит недооценивать. peer review — лучшая сила в медицине, науке и программировании. При этом решаются бизнес-задачи, но превращение программиста в кодера режима офисного планктона лишает компанию второго из ресурсов, которые предоставляет программист за свою зарплату.
Ресурсов два: время и энтузиазм.
И scrum решает проблему времени. А вот вопрос энтузиазма решает атмосфера проекта и возможность самовыражения.
Можно отнять возможность самовыражения, но в этом случае компания просто заплатит больше денег за меньшее. Потому что «охота пуще неволи» и влияет очень сильно на качественные (в смысле «переход количества в качество») характеристики реализуемого.
Проблема в том, что программист и дворник имеют разные пороги входа в профессию. Как результат — Вам будет гораздо сложнее понять, как программисту «правильнее держать лопату». Именно поэтому я предложил вам найти хорошего программиста, который сможет дать реальную оценку эффективности кода.
А вот как раз «нефиг парится с архитектурой, сгамнякайте хоть чтонибудь» — приводит к очень плачевным результатам. К текучке например. Почитайте Демарко PeopleWare — он об этом гараздо лучше меня пишет.
А вот как раз «нефиг парится с архитектурой, сгамнякайте хоть чтонибудь» — приводит к очень плачевным результатам. К текучке например. Почитайте Демарко PeopleWare — он об этом гараздо лучше меня пишет.
Не, я тут не при чём. Вы мне зачем-то чужие слова приписываете. Моя позиция — не такая, как вы описали «нефиг париться с архитектурой», а вы зачем-то с голосами в голове спорите. Или я не знаю, с кем.
Моя позиция — код должен быть _достаточного хорошим_, но не лучше. Я это уже выше писал. Нельзя бесконечно полировать инструменты, иногда надо и копать.
Вы с этим спорите, что ли? Код не должен быть достаточно хорошим? Или код должен быть более, чем достаточно хорошим? Выберите какой-нибудь вариант, а то я только слышу от вас, что я не прав.
К сожалению, «хорошие» программисты (в общечеловеческом понимании этого слова) часто ставят перед собой чучело идеальной архитектуры и молятся на него; что там надо бизнесу, их волнует редко. И очень часто всё приходит в состояние «всё было красиво спроектировано, но вот бизнес туда не очень ложится». Вовремя понять, что иногда и говнокоду есть место, ибо это объективное отражение того беспорядка, что творится в бизнесе — это очень важно.
Если программист это не хочет принять, то выше mid developer его ставить не стоит, увы. Если ему не нравится хаос бизнеса — пусть начинает переделывать бизнес-процессы; потому что недельные рефакторинги не окупаются совершенно.
Моя позиция — код должен быть _достаточного хорошим_, но не лучше. Я это уже выше писал. Нельзя бесконечно полировать инструменты, иногда надо и копать.
Вы с этим спорите, что ли? Код не должен быть достаточно хорошим? Или код должен быть более, чем достаточно хорошим? Выберите какой-нибудь вариант, а то я только слышу от вас, что я не прав.
К сожалению, «хорошие» программисты (в общечеловеческом понимании этого слова) часто ставят перед собой чучело идеальной архитектуры и молятся на него; что там надо бизнесу, их волнует редко. И очень часто всё приходит в состояние «всё было красиво спроектировано, но вот бизнес туда не очень ложится». Вовремя понять, что иногда и говнокоду есть место, ибо это объективное отражение того беспорядка, что творится в бизнесе — это очень важно.
Если программист это не хочет принять, то выше mid developer его ставить не стоит, увы. Если ему не нравится хаос бизнеса — пусть начинает переделывать бизнес-процессы; потому что недельные рефакторинги не окупаются совершенно.
А я и не лезу в красоту кода, я оперирую с другими понятиями. Никакие бюрократические стандарты не заменят peer review, именно на него мы и полагаемся при оценке качества кода (с точки зрения программиста). С моей же точки зрения (как Product Owner) меня интересует во-первых возможность продолжать развитие без постоянного нудёжа «всё переписывать надо», а во-вторых сроки реализации payload (то есть полезной части проекта).
Условно говоря, если программисты считают, что в этом месте нужно сделать DSL и пойти «на уровень выше», то я для себя считаю, что они это хотят во имя вселенского добра, то есть проекту от этого станет лучше (от странных взбрыков отдельных людей вполне спасает коллегиальность решения и способность аргументировать это окружающим). После этого предложения я примерно оцениваю сложность реализации и думаю, «оно нам надо?». Думаю я исходя из ценности проекта — чем проект/компонет ценнее, тем более я соглашаюсь с выделением ресурсов на его метапрограммирование.
Я не могу сказать, что я «не разбираюсь в программировании» (хотя да, всякие игры в семигрупоиды и template haskell — это выше моего уровня компетенции). Я вполне свободно пишу на Си, питоне и т.д., не говоря уже про прикладные шелловые скрипты, так что первое приближение обсуждаемой идее я дать могу. А тонкости (вроде того, какую библиотеку в Хаскеле использовать для работы с postgres, и как именно декларируются типы в datamodel) — это уже к программистам. Впрочем, в дискуссии нужно ли тип делать Maybe я обычно всё-таки участвую, т.к. источники данных в БД — это моя вотчина.
Надо сказать, что я не являюсь «руководителем» над программистами. Я PO, условно, финальный источник информации о бизнес-логике, устройству нижележащих слоёв, инфраструктуре, направлении развития проекта и т.д. Если у нас возникает какая-то серьёзная проблема в взаимопонимании, то проблема эскалируется к техническому директору, который уже оперирует на другом понятийном пространстве и решает «нерешаемый» конфликт административными методами.
Надо понимать, что у программистов есть определённые деформации сознания — для них код и есть программа, а главным её достоинством является удобство её дописывания. С точки зрения же бизнеса главным достоинством программы является мнение о ней клиентов и генерируемая revenue. Я нахожусь по середине, то есть могу и программистов «обломать» с чрезмерным увлечением метапрограммированием и ткнуть в необходимость вести легаси, и на совещании возражать против изменений, которые «вот тут побыстрому доделать».
Причём второе — это особое искусство, т.к. говорить нужно на языке, термины которого описывают бизнес. То есть никого не интересует чистота кода или архитектурное совершенство. А вот цена сопровождения и предсказуемые сроки реализации годового плана — вполне волнуют и понятны.
Условно говоря, если программисты считают, что в этом месте нужно сделать DSL и пойти «на уровень выше», то я для себя считаю, что они это хотят во имя вселенского добра, то есть проекту от этого станет лучше (от странных взбрыков отдельных людей вполне спасает коллегиальность решения и способность аргументировать это окружающим). После этого предложения я примерно оцениваю сложность реализации и думаю, «оно нам надо?». Думаю я исходя из ценности проекта — чем проект/компонет ценнее, тем более я соглашаюсь с выделением ресурсов на его метапрограммирование.
Я не могу сказать, что я «не разбираюсь в программировании» (хотя да, всякие игры в семигрупоиды и template haskell — это выше моего уровня компетенции). Я вполне свободно пишу на Си, питоне и т.д., не говоря уже про прикладные шелловые скрипты, так что первое приближение обсуждаемой идее я дать могу. А тонкости (вроде того, какую библиотеку в Хаскеле использовать для работы с postgres, и как именно декларируются типы в datamodel) — это уже к программистам. Впрочем, в дискуссии нужно ли тип делать Maybe я обычно всё-таки участвую, т.к. источники данных в БД — это моя вотчина.
Надо сказать, что я не являюсь «руководителем» над программистами. Я PO, условно, финальный источник информации о бизнес-логике, устройству нижележащих слоёв, инфраструктуре, направлении развития проекта и т.д. Если у нас возникает какая-то серьёзная проблема в взаимопонимании, то проблема эскалируется к техническому директору, который уже оперирует на другом понятийном пространстве и решает «нерешаемый» конфликт административными методами.
Надо понимать, что у программистов есть определённые деформации сознания — для них код и есть программа, а главным её достоинством является удобство её дописывания. С точки зрения же бизнеса главным достоинством программы является мнение о ней клиентов и генерируемая revenue. Я нахожусь по середине, то есть могу и программистов «обломать» с чрезмерным увлечением метапрограммированием и ткнуть в необходимость вести легаси, и на совещании возражать против изменений, которые «вот тут побыстрому доделать».
Причём второе — это особое искусство, т.к. говорить нужно на языке, термины которого описывают бизнес. То есть никого не интересует чистота кода или архитектурное совершенство. А вот цена сопровождения и предсказуемые сроки реализации годового плана — вполне волнуют и понятны.
А, да, знал такого. Правда максимальное кол-во посетителей на сайте — было 1 (потом сайт умирал), смотреть на несовсем новых компьютерах карту было нереально, а при фиксе одной фичи — отпадала другая. А специалист — классный, да. И работал быстро.
Отличное наблюдение! В некоторых банках этот замечательный подход работает на ура. С ужасом вспоминаю клиент-банк, реализованный на почтовых ящиках, систему бюджетирования максимум на 75 клиентов и папку на 300 батничков с именами asasas.bat. Всё работает, к программистам приходишь — сидят смотрят фильмы, а ближайшие две недели выделены на таск «рефакторинг кода». И все при деле.
Ну а когда код перестанет умещаться в голове, как, по-вашему, он будет работать? Могу сразу сказать — плохо, плюс начнутся потуги переписать все начисто, потому что старый код перестал быть прозрачным, а тестов нет. Знаю, в том числе, и по себе.
Если код «перестаёт укладывается в голову» и его хочется сопровождать — то это не тот случай, про который я говорю. Ценность кода надо уметь измерять.
А тот случай, про который вы говорите — это не разработка, это просто кодирование, не надо приплетать тут технологии для разработки ПО, которые ориентированы на полный цикл кодирование-тестирование-поддержка, плюс работу в команде.
Если разработчик стреляет из пушки по воробьям, это явно ошибка. И не факт что его. Многие заказчики говорят, что это лишь на один раз, а в итоге «одноразовый» код потом годами пьет кровь тех, кто его поддерживает.
Если разработчик стреляет из пушки по воробьям, это явно ошибка. И не факт что его. Многие заказчики говорят, что это лишь на один раз, а в итоге «одноразовый» код потом годами пьет кровь тех, кто его поддерживает.
Я про это и говорю. Но дело в том, что деление «сопровождаемый проект»/«одноразовый код» не бинарное. Классификация больше/меньше — удел PO. И его же обязанность решить, что делать с одноразовым кодом, который начал перерастать в крупный проект.
Блин, я только что понял, что работаю по JSDD методологии! :DDD
Мелкие аутсорсеры одобряют.
В целом, достаточно разумный подход :)
Можно легко все перевернуть с ног на голову и написать «Programming for Programming Sake Driven Development» (или PPSDD).
Планирование — планирование задач должно быть как можно более долгим. Каждую деталь нужно решить и документировать заранее, все UML-диаграммы должны быть сертифицированы по ISO и подписаны Ведущим Разработчиком, Зам. Ведущего Разработчика и Ведущим Инженером по Подписыванию Диаграмм. Созвоны и чаты запрещены, все изменения документируются исключительно через тикеты в Системе Контроля Изменения Спецификаций (СКИС).
Рефакторинг — самая главная задача заключается в понятности кода, а не в решении бизнес-задач! Поэтому как только решение начинает работать, разработчик должен ставить специальную задачу по рефакторингу и тут же приниматься за нее. Каждый рефакторинг также можно пропустить через дополнительный рефакторинг рефакторинга, и желательны code review как кода после первого рефакторинга, так и после 2 и 3. Закрывать задачу по рефакторингу можно только после того, как все члены команды сдадут экзамен на понимание каждой строчки кода. Конечно, до выкладки этого в production.
Фреймворкозависимость — как известно, все давно написано за нас. Поэтому перед написанием кода необходимо защитить перед коллегами выбор без-фреймворкового подхода. Несомненно, если на сайте нужен, например, календарь, надо подключить jQuery UI. Кроме того, требования к проекту развиваются и меняются, и смена одного фреймворка на другой даст богатую пищу для возлюбленного рефакторинга.
Решения на будущее — архитектурные решения, которые принимаются на проекте, должны быть как можно больше адаптированы к изменениям. Нужно полностью планировать, какой компонент каким функционалом может обладать в будущем. Например, если это календарь (см. выше), то нужно расширить ядро таким образом, чтобы «в один клик» изменить формат вывода с 10-тичной на любую другую систему счисления, а также сменить грегорианский календарь на календарь в произвольной форме, описывающийся структурой в XML-файле, для которого также следует написать специальный парсер, который также следует адаптировать к генерации произвольных форматов XML не только для календарей, но и рецептов, вдруг у вас на сайте появятся рецепты?..
Полное тестирование кода — каждый разработчик знает, что тестировать код намного важнее, чем все остальное. В рамках «решений на будущее» также следует предусмотреть максимум возможных use case и написать для них соответствующие тесты. Так как тесты подвержены эволюции, то их сами тоже нужно тестировать. Также необходимо тестировать саму систему запуска тестов, и систему отображения результатов тестов. Желательно также тестировать каждого разработчика с утра перед выходом на работу.
Командная работа — вам нужно полностью поделиться вашими знаниями со всеми остальными, поэтому лучше всего не останавливаться на парном программировании, ведь можно заниматься и программированием четверками, десятками или целыми батальонами программистов. Каждый новый человек — дополнительный приемник ваших знаний и гарантия того, что все знания распределятся по команде максимально равномерным образом.
Только готовые решения — как только вы видите возможность использовать общеизвестный инструмент или подход — используйте его. Ведь это единственный способ создать Вечный код. Если у вас есть идея лучше, или проще — подумайте, ведь до вас работали неглупые люди, наверняка у вас где-то будет ошибка или неточность. Проще взять готовое. К тому же, вы должны чтить паттерны проектирования, потому что вы должны их чтить, потому что вы должны.
Отсутствие спешки — код вечен, а бизнес скоротечен. Не давайте коллегам увлечь вас вихрем рынка, ведь ваш код все это переживет, он будет полностью покрыт тестами и готов к переходу в 23-й век, а бизнес уже давно закроется или переориентируется. Код — это главное. Бизнес ничто.
Можно легко все перевернуть с ног на голову и написать «Programming for Programming Sake Driven Development» (или PPSDD).
Планирование — планирование задач должно быть как можно более долгим. Каждую деталь нужно решить и документировать заранее, все UML-диаграммы должны быть сертифицированы по ISO и подписаны Ведущим Разработчиком, Зам. Ведущего Разработчика и Ведущим Инженером по Подписыванию Диаграмм. Созвоны и чаты запрещены, все изменения документируются исключительно через тикеты в Системе Контроля Изменения Спецификаций (СКИС).
Рефакторинг — самая главная задача заключается в понятности кода, а не в решении бизнес-задач! Поэтому как только решение начинает работать, разработчик должен ставить специальную задачу по рефакторингу и тут же приниматься за нее. Каждый рефакторинг также можно пропустить через дополнительный рефакторинг рефакторинга, и желательны code review как кода после первого рефакторинга, так и после 2 и 3. Закрывать задачу по рефакторингу можно только после того, как все члены команды сдадут экзамен на понимание каждой строчки кода. Конечно, до выкладки этого в production.
Фреймворкозависимость — как известно, все давно написано за нас. Поэтому перед написанием кода необходимо защитить перед коллегами выбор без-фреймворкового подхода. Несомненно, если на сайте нужен, например, календарь, надо подключить jQuery UI. Кроме того, требования к проекту развиваются и меняются, и смена одного фреймворка на другой даст богатую пищу для возлюбленного рефакторинга.
Решения на будущее — архитектурные решения, которые принимаются на проекте, должны быть как можно больше адаптированы к изменениям. Нужно полностью планировать, какой компонент каким функционалом может обладать в будущем. Например, если это календарь (см. выше), то нужно расширить ядро таким образом, чтобы «в один клик» изменить формат вывода с 10-тичной на любую другую систему счисления, а также сменить грегорианский календарь на календарь в произвольной форме, описывающийся структурой в XML-файле, для которого также следует написать специальный парсер, который также следует адаптировать к генерации произвольных форматов XML не только для календарей, но и рецептов, вдруг у вас на сайте появятся рецепты?..
Полное тестирование кода — каждый разработчик знает, что тестировать код намного важнее, чем все остальное. В рамках «решений на будущее» также следует предусмотреть максимум возможных use case и написать для них соответствующие тесты. Так как тесты подвержены эволюции, то их сами тоже нужно тестировать. Также необходимо тестировать саму систему запуска тестов, и систему отображения результатов тестов. Желательно также тестировать каждого разработчика с утра перед выходом на работу.
Командная работа — вам нужно полностью поделиться вашими знаниями со всеми остальными, поэтому лучше всего не останавливаться на парном программировании, ведь можно заниматься и программированием четверками, десятками или целыми батальонами программистов. Каждый новый человек — дополнительный приемник ваших знаний и гарантия того, что все знания распределятся по команде максимально равномерным образом.
Только готовые решения — как только вы видите возможность использовать общеизвестный инструмент или подход — используйте его. Ведь это единственный способ создать Вечный код. Если у вас есть идея лучше, или проще — подумайте, ведь до вас работали неглупые люди, наверняка у вас где-то будет ошибка или неточность. Проще взять готовое. К тому же, вы должны чтить паттерны проектирования, потому что вы должны их чтить, потому что вы должны.
Отсутствие спешки — код вечен, а бизнес скоротечен. Не давайте коллегам увлечь вас вихрем рынка, ведь ваш код все это переживет, он будет полностью покрыт тестами и готов к переходу в 23-й век, а бизнес уже давно закроется или переориентируется. Код — это главное. Бизнес ничто.
Красиво получилось! Да, антипрактики есть по обе стороны баррикад.
И как же быть теперь. :) Мне, к примеру, за почти 15 лет практики разного программирования, *чаще всего* приходится встречаться с мусорным кодом. Не в смысле, что он плохой, а в смысле, что его нужно выбрасывать. В него вложили деньги, силы, труд, но он просто больше не нужен. Есть вещи «на века», но их намного меньше, особенно в веб-разработке. Конечно, если у вас софтовая компания, или вы делаете какие-то generic вещи, как Oracle или Microsoft, то вы можете вкладываться в качество кода. В вебе, особенно в продажах, общий успех зачастую зависит от качества системы в целом — проектирования бизнес-процессов, маркетинга, бэк-офиса, HR и др. И в мире наблюдается четкая тенденция к перевешиванию этой сугубо материальной и бизнес-составляющей в т.ч. и в софтовых продуктах.
Забыли добавить вывод, описывающий, в чем же профит для программиста:
«Выбирайте только те системы, фреймворки и библиотеки, которые также разрабатываются по принципам PPSDD — например, Android, Yii и Drupal. Подобные системы также постоянно рефакторятся без оглядки на совместимость с предыдущими версиями. А так как вы делегировали им всю реальную работу, при выходе очередного еженедельного обновления никто кроме вас не сможет запустить вашу программу. Это железобетонная гарантия, что вас не уволят».
«Выбирайте только те системы, фреймворки и библиотеки, которые также разрабатываются по принципам PPSDD — например, Android, Yii и Drupal. Подобные системы также постоянно рефакторятся без оглядки на совместимость с предыдущими версиями. А так как вы делегировали им всю реальную работу, при выходе очередного еженедельного обновления никто кроме вас не сможет запустить вашу программу. Это железобетонная гарантия, что вас не уволят».
Отлично! Я именно так и стараюсь работать. Кому он нужен, этот бизнес :)
Это вы еще забыли про Систему Централизованного Управления Клиентскими Обращениями :-)
Хочу поделиться своим грустным опытом в Agile.
В данный момент я являюсь ТимЛидом в одном из многих стартапов. Как и другие, наш стартап начинался с идеи и пилотной альфа-версии для демонстрации идеи инвесторам. После нескольких итераций идея приобрела некий приемлемый для инвесторов вид и было дано добро на развитие. Новоявленные продакт менеджеры и инвесторы добавляли все новые и новые фичи в проект и, как водится в СНГшном бизнесе, просили результаты работы «на вчера». В этот момент случилась первая и решающая ошибка команды разработчиков(к которой, на тот момент, относился и я сам). Они начали внедрять новые фичи не задумываясь о модели и не документируя свои решения. Тоесть для каждой задачи выбирался подходящий по форме и размеру костыль и подставлялся, потому что инвесторы хотели увидить эту фичу еще вчера.
Прошел год такой разработки. Все дедлайны были провалены, часть людей ушла из проекта, часть добавилась. Я стал тимлидом. Один из менеджеров решил, что для повышения эффективности команды ей стоит работать, придерживаясь Scrum`а. Он был введен. И вот, после 10 спринтов, вся команда начала понимать, что велкикий и могучий Скрам не помогает нам работать. Потому что нет костяка(читай ТЗ), который можно было бы гибко менять в заисимости от отклика юзеров. Овнер(он же менеджер, предложивший Скрам) продолжает требовать от команды новых костылей и не хочет обращать внимания на глобальные проблемы модели приложения, команда продолжает пилитьгири костыли. Каждый день я жду новых падений модели-инвалида и пытаюсь убедить Овнера, что нужно приостановиться и обновить модель.
Мораль сей басни такова: гибкая разработка — это круто, но каждому необходимо понимать, когда ней можно начинать пользоваться, а когда еще рано.
В данный момент я являюсь ТимЛидом в одном из многих стартапов. Как и другие, наш стартап начинался с идеи и пилотной альфа-версии для демонстрации идеи инвесторам. После нескольких итераций идея приобрела некий приемлемый для инвесторов вид и было дано добро на развитие. Новоявленные продакт менеджеры и инвесторы добавляли все новые и новые фичи в проект и, как водится в СНГшном бизнесе, просили результаты работы «на вчера». В этот момент случилась первая и решающая ошибка команды разработчиков(к которой, на тот момент, относился и я сам). Они начали внедрять новые фичи не задумываясь о модели и не документируя свои решения. Тоесть для каждой задачи выбирался подходящий по форме и размеру костыль и подставлялся, потому что инвесторы хотели увидить эту фичу еще вчера.
Прошел год такой разработки. Все дедлайны были провалены, часть людей ушла из проекта, часть добавилась. Я стал тимлидом. Один из менеджеров решил, что для повышения эффективности команды ей стоит работать, придерживаясь Scrum`а. Он был введен. И вот, после 10 спринтов, вся команда начала понимать, что велкикий и могучий Скрам не помогает нам работать. Потому что нет костяка(читай ТЗ), который можно было бы гибко менять в заисимости от отклика юзеров. Овнер(он же менеджер, предложивший Скрам) продолжает требовать от команды новых костылей и не хочет обращать внимания на глобальные проблемы модели приложения, команда продолжает пилить
Мораль сей басни такова: гибкая разработка — это круто, но каждому необходимо понимать, когда ней можно начинать пользоваться, а когда еще рано.
«Скрам говно, потому что архитектура приложения плохая»?
Я не говорю, что скрам говно. Я говорю, что нужно вовремя ним пользоваться, иначе этот инструмент больше вредит, чем помогает. В данный момент я знаю, что арзитектура говно, знаю почему, есть предложения по исправлению, но в ответ меня настоятельно просят ближайший спринт посвятить багфиксингу, а рефакторинг будет позже. Вот только это позже не обозримо.
Ну, спринт-второй багфиксинга — хорошая возможность отрефакторить хотя бы ключевые участки кода, а ПМ даже ничего и не узнает.
Багфиксинг касается интерфейса в основном. А для основных участков кода требуетсяс недели 2-3 рефакаторинга, при чем проект загажен настолько, что сделать эти правки паралельно с текущим работающим кодом просто нереально. Все завалится к черту. Код сильносвязан и малейшие колебания в одном месте наочно демонстрируют теорию хаоса.
Учитесь делать латентные эпики. Это такие epic'и, которые выполняются по 1-2 issue (на 1-2 story point) в неделю.
У меня, например, есть вяло ползущий эпик, который тянется уже больше года. Выполнен на 60%. При этом мне бы никто такое количество программисто-недель в эксклюзив не дал бы. А вот мягко и неторопливо делать сложные изменения — самое то.
Но тут другая проблема — кто-то должен написать issue так, чтобы от мелких исправлений (меняющих архитектуру) была бы локальная польза (или хотя бы не было бы вреда).
Худший вид рефакторинга — это когда «новая крутая модель» просто не совместима со старой и требует внимания к себе, а не к совместимости. Условно говоря, сломали, пишут, будет офигенно, а вот всякие мелкие вещи, которые и есть бизнес-логика, оставляются на потом, да ещё часть и выкидывают, ибо «не совместимо с новой моделью».
Отсюда мораль — должен быть человек, который ведёт проект. Не в смысле сакральных знаний, а в смысле «чувства правильного».
У меня, например, есть вяло ползущий эпик, который тянется уже больше года. Выполнен на 60%. При этом мне бы никто такое количество программисто-недель в эксклюзив не дал бы. А вот мягко и неторопливо делать сложные изменения — самое то.
Но тут другая проблема — кто-то должен написать issue так, чтобы от мелких исправлений (меняющих архитектуру) была бы локальная польза (или хотя бы не было бы вреда).
Худший вид рефакторинга — это когда «новая крутая модель» просто не совместима со старой и требует внимания к себе, а не к совместимости. Условно говоря, сломали, пишут, будет офигенно, а вот всякие мелкие вещи, которые и есть бизнес-логика, оставляются на потом, да ещё часть и выкидывают, ибо «не совместимо с новой моделью».
Отсюда мораль — должен быть человек, который ведёт проект. Не в смысле сакральных знаний, а в смысле «чувства правильного».
Вот тут как раз и вся беда.
Три менеджера, у каждого из которых бывают свои взгляды на то, как должно быть.
По поводу «новой крутой модели» хохма в том, что она как раз нужна для реализации бизнес логики, которую на текущей модели реализовать просто нереально, она не заложена в модель. Вот так и живем. Мобильное приложение, которое занимает в данный момент 240 Мб в памяти, выполнять можето только 2/3 из бизнес задач, но рюшики важнее.
Три менеджера, у каждого из которых бывают свои взгляды на то, как должно быть.
По поводу «новой крутой модели» хохма в том, что она как раз нужна для реализации бизнес логики, которую на текущей модели реализовать просто нереально, она не заложена в модель. Вот так и живем. Мобильное приложение, которое занимает в данный момент 240 Мб в памяти, выполнять можето только 2/3 из бизнес задач, но рюшики важнее.
Проблемы организационной сферы. Надо найти язык, на котором объяснить проблему. Обычный язык в таком случае — перевод на деньги.
Время сотрудников = деньги. Повышение эффективности = снижение затрат.
Другая проблема, что нужно быть готовым, что если вам скажут «ок, переписывайте» (то есть инвестируют сколько-то денег), то нужно показать в ответ повышение скорости.
Если разницы между «пишем красиво» и «всё время докоживаем» по итоговой функциональности и скорости разработки нет — значит, судьба проекта будет «всё время докоживаем».
Иными словами, нужно не просто просить ресурсы на переписывание, но и возвращать инвестиции.
Время сотрудников = деньги. Повышение эффективности = снижение затрат.
Другая проблема, что нужно быть готовым, что если вам скажут «ок, переписывайте» (то есть инвестируют сколько-то денег), то нужно показать в ответ повышение скорости.
Если разницы между «пишем красиво» и «всё время докоживаем» по итоговой функциональности и скорости разработки нет — значит, судьба проекта будет «всё время докоживаем».
Иными словами, нужно не просто просить ресурсы на переписывание, но и возвращать инвестиции.
Agile не спасет проект, в котором не было требований ни в каком более-менее адекватном виде. Так же как и проект-калеку на костылях. Это миф, который многие (а именно адепты Scrum, но далеко не все) пытаются успешно продавать.
А довел до текущего состояния еще один интересный миф из мира стартапов — можно делать как угодно, лишь бы быстрей взлететь. Так действительно в большей части делать разумно, но есть нюанс — долго так не протянуть. Обычно люди просто читают между строк и этот факт упускают. А дальше аргументация «мы как все другие стартапы, посмотрите по сторонам»…
А довел до текущего состояния еще один интересный миф из мира стартапов — можно делать как угодно, лишь бы быстрей взлететь. Так действительно в большей части делать разумно, но есть нюанс — долго так не протянуть. Обычно люди просто читают между строк и этот факт упускают. А дальше аргументация «мы как все другие стартапы, посмотрите по сторонам»…
Причем тут скрам и ТЗ? Проблема совершенно не в этом.
1) Скрам и дедлайн несовместимы. В скраме фича готова, когда команда говорит, что фича готова. Для этого команда работает столько сколько нужно. Если это не так, то у вас не скрам, а бардак.
2) Планирование фичи должно заключаться в проработке User Story. Для Story должны быть как минимум определены сценарии и критерии приемки. Набор сторей и будет ваше ТЗ. Если такого нет, то это не скрам, а бардак.
3) В скраме нужно планировать релизы. Одна итерация перед релизом обычно уделяется на «вылизывание» продукта: устранение дефектов с прошлого релиза, устранение некритичных багов (фичи с критичными багами просто не включаются в релиз) итд. Если такого нет, то это не скрам, а бардак.
4) Если в скраме не удается уложиться в план (итерации, релиза), то всегда жертвуются фичи. Если к релизу недостаточно фич, то надо просто признать фейл, перенести релиз, пересчитать velocity, учесть при планировании следующего релиза и продолжать работать в том же темпе. Никакого форсирования работ не допускается. Если такого нет… ну вы поняли.
Основной фокус скрама — ритмичные релизы, более стабильное получение фидбека и включение его в разработку, создание продукта, максимально удовлетворяющего клиента. Это достигается фактически снижением темпа выпуска фич и закрытия багов.
Если смотреть на треугольник полезность-качество-скорость, то скрам торгует скорость на полезность.
1) Скрам и дедлайн несовместимы. В скраме фича готова, когда команда говорит, что фича готова. Для этого команда работает столько сколько нужно. Если это не так, то у вас не скрам, а бардак.
2) Планирование фичи должно заключаться в проработке User Story. Для Story должны быть как минимум определены сценарии и критерии приемки. Набор сторей и будет ваше ТЗ. Если такого нет, то это не скрам, а бардак.
3) В скраме нужно планировать релизы. Одна итерация перед релизом обычно уделяется на «вылизывание» продукта: устранение дефектов с прошлого релиза, устранение некритичных багов (фичи с критичными багами просто не включаются в релиз) итд. Если такого нет, то это не скрам, а бардак.
4) Если в скраме не удается уложиться в план (итерации, релиза), то всегда жертвуются фичи. Если к релизу недостаточно фич, то надо просто признать фейл, перенести релиз, пересчитать velocity, учесть при планировании следующего релиза и продолжать работать в том же темпе. Никакого форсирования работ не допускается. Если такого нет… ну вы поняли.
Основной фокус скрама — ритмичные релизы, более стабильное получение фидбека и включение его в разработку, создание продукта, максимально удовлетворяющего клиента. Это достигается фактически снижением темпа выпуска фич и закрытия багов.
Если смотреть на треугольник полезность-качество-скорость, то скрам торгует скорость на полезность.
Что за паранойя?
1. Дедлайны всегда есть, просто в скраме под них подгоняется скоуп (сколько успеем сделать к дате дедлайна). Есть альтернативный подход с датами дедлайна в зависимости от времени на фиксированный скоуп. Но без дедлайнов разработка практически возможна только в теории. «Команда работает сколько нужно» — идеализированный подход для сверхкоманды, да и то на нее будет действовать закон Паркинсона.
2. Тут я с вами согласен по поводу необходимости требований и формат User Story мне тоже нравится. Но в скраме он не предписывается в качестве обязательного. Знаю много команд, в которых замечательно работают в скраме другие процессы управления требованиями.
3. При таком подходе вы все дальше от Continuous Delivery. Вы же сами в первом пункте сказали, что стори готова когда команда сказала «ГОТОВО». Так о каких доработках и фиксах идет речь? Это в простонародье называется стабилизационной итерацией и многие считают это антипаттерном.
4. Тут я снова с вами соглашусь. Есть соблазн «немного поднажать», но он может привести к плохим последствиям.
А вот по поводу снижения темпа я с вами категорически не согласен. Тут речь не только о стабильности, но и о скорости разработки. На протяжение итерации команду не отвлекают разной ерундой, на планировании и в ходе разработки дают все необходимое, не давят по срокам, все прозрачно и контролируемо. Поэтому при правильном применении скрама скорость разработки не падает.
1. Дедлайны всегда есть, просто в скраме под них подгоняется скоуп (сколько успеем сделать к дате дедлайна). Есть альтернативный подход с датами дедлайна в зависимости от времени на фиксированный скоуп. Но без дедлайнов разработка практически возможна только в теории. «Команда работает сколько нужно» — идеализированный подход для сверхкоманды, да и то на нее будет действовать закон Паркинсона.
2. Тут я с вами согласен по поводу необходимости требований и формат User Story мне тоже нравится. Но в скраме он не предписывается в качестве обязательного. Знаю много команд, в которых замечательно работают в скраме другие процессы управления требованиями.
3. При таком подходе вы все дальше от Continuous Delivery. Вы же сами в первом пункте сказали, что стори готова когда команда сказала «ГОТОВО». Так о каких доработках и фиксах идет речь? Это в простонародье называется стабилизационной итерацией и многие считают это антипаттерном.
4. Тут я снова с вами соглашусь. Есть соблазн «немного поднажать», но он может привести к плохим последствиям.
А вот по поводу снижения темпа я с вами категорически не согласен. Тут речь не только о стабильности, но и о скорости разработки. На протяжение итерации команду не отвлекают разной ерундой, на планировании и в ходе разработки дают все необходимое, не давят по срокам, все прозрачно и контролируемо. Поэтому при правильном применении скрама скорость разработки не падает.
1. Дедлайн означает что к сроку нужно сдать работу в полном объеме. В скраме нет такого. В скраме есть release plan, про это пункты 3-4 предыдущего коммента.
3. В книжном описании скрама есть недостаток. Там считается что все баги устраняются в ходе разработки. Acceptance тесты не ловят всех багов, тестеры тоже люди, допускают ошибки. Поэтому перед релизом продукта таки надо тратить время на вылизывание. Чтобы это уложить в скрам и делается вылизывательная итерация, иначе будет попытка увеличить темп разработки, что скажется на качестве.
Хотя если вы пилите публичный сайт, то возможно имеет смысл иметь команду разработки и команду поддержи. Первая струячит фичи, вторая выкладывает результаты итерации в продакшн и фиксит проблемы. Каждый релиз команды меняются.
Да, практика показывает что правильное применение скрама делает работу более равномерной, и в среднем продуктивность растет из-за отсутствия переключений между задачами, персонального commitment_а разработчиков и раннего устранения дефектов. Но изначально все это достигается снижением темпа разработки, а преимущества появляются не сразу и только если менеджмент не мешает.
3. В книжном описании скрама есть недостаток. Там считается что все баги устраняются в ходе разработки. Acceptance тесты не ловят всех багов, тестеры тоже люди, допускают ошибки. Поэтому перед релизом продукта таки надо тратить время на вылизывание. Чтобы это уложить в скрам и делается вылизывательная итерация, иначе будет попытка увеличить темп разработки, что скажется на качестве.
Хотя если вы пилите публичный сайт, то возможно имеет смысл иметь команду разработки и команду поддержи. Первая струячит фичи, вторая выкладывает результаты итерации в продакшн и фиксит проблемы. Каждый релиз команды меняются.
Да, практика показывает что правильное применение скрама делает работу более равномерной, и в среднем продуктивность растет из-за отсутствия переключений между задачами, персонального commitment_а разработчиков и раннего устранения дефектов. Но изначально все это достигается снижением темпа разработки, а преимущества появляются не сразу и только если менеджмент не мешает.
Ага, а теперь вопрос: если начинает падать velocity, то мы снижаем и снижаем? А народ мирно ковыряется в коде, жертвуя фичами. Ну-ну…
Если начинает падать velocity, то надо разобраться почему. Чаще всего velocity падает из-за того что есть working to deadline и нету достаточно тестирования в итерации, от этого появляется много багов, которые отъедают часть работы в следующей итерации.
Надо снижать темп в таком случае.
Надо снижать темп в таком случае.
То есть вариант «кто-то начал халтурить» не рассматривается в принципе? В этом и печаль agile, он говорит «у нас команда энтузиастов и не мешайте ей работать максимально продуктивно, а только помогайте». А если нет? Если кто-то просто ленится или ему что-то не нравится?
Любая попытка подпнуть разрабочика на тему «пиши быстрее» воспринимается как покушение на принципы agile.
Безусловно, бывает, что задача рассчитана неправильно. Но бывает — что просто ленится. Вот я сейчас поеду на митинг и буду вопрошать человека, почему он за весь недельный спринт сделал только три issue на пять сторипоинтов. Причём для одного из них он поменял оценку с «1» до 3 (ок, ок), но это совсем не отвечает на вопрос, чем он занимался всё остальное время.
Любая попытка подпнуть разрабочика на тему «пиши быстрее» воспринимается как покушение на принципы agile.
Безусловно, бывает, что задача рассчитана неправильно. Но бывает — что просто ленится. Вот я сейчас поеду на митинг и буду вопрошать человека, почему он за весь недельный спринт сделал только три issue на пять сторипоинтов. Причём для одного из них он поменял оценку с «1» до 3 (ок, ок), но это совсем не отвечает на вопрос, чем он занимался всё остальное время.
Кто-то это кто? Ведь очень легко отслеживается по истории задач кто сколько работы сделал по истории итерации. Задачи кстати оцениваются в часах, так что низкая продуктивность одного человека будет видна сразу же. Но пока проблем нет (velocity не падает), оценивать индивидуальные метрики нельзя. Это кстати не в скраме написано, а в TSP.
Естественно если есть проблемы надо разбираться в причинах, а не просто «пиши быстрее», иначе качество упадет. Я вот в своей жизни ни разу не видел чтобы человек работал хорошо, а потом внезапно начал работать плохо. Скорее всего для этого есть очень явные причины.
Естественно если есть проблемы надо разбираться в причинах, а не просто «пиши быстрее», иначе качество упадет. Я вот в своей жизни ни разу не видел чтобы человек работал хорошо, а потом внезапно начал работать плохо. Скорее всего для этого есть очень явные причины.
… Например, человек вылетел из графика, всё время хочет спать и вообще, не до (этого нелюбимого) проекта.
Что значит «вылетел из графика» откуда у него график? Velocity падает? Если нет, то не надо заниматься микро-менеджментом.
Такая ситуация была изначально? Или «внезапно» появилась?
Если изначально, то почему это не было видно на daily scrum? Если человек постоянно не укладывается в сроки задач, то это сразу видно — банально нечего сказать на daily scrum… Значит надо его учить\мотивировать\исключать из проекта.
Если появилась внезапно — надо разобраться с причинами. Например у нас есть один парень, который пошел дополнительно учиться, теперь спит мало, работает плохо. Возможно ему просто часть рабочего времени и ЗП срежут, чтобы планирование не ломалось.
Не зная причины предпринимать любые действия неэффективно, можно нарваться на противоположное действие.
Такая ситуация была изначально? Или «внезапно» появилась?
Если изначально, то почему это не было видно на daily scrum? Если человек постоянно не укладывается в сроки задач, то это сразу видно — банально нечего сказать на daily scrum… Значит надо его учить\мотивировать\исключать из проекта.
Если появилась внезапно — надо разобраться с причинами. Например у нас есть один парень, который пошел дополнительно учиться, теперь спит мало, работает плохо. Возможно ему просто часть рабочего времени и ЗП срежут, чтобы планирование не ломалось.
Не зная причины предпринимать любые действия неэффективно, можно нарваться на противоположное действие.
Бороться с такой ленью достаточно просто — надо работать в паре на таких задачах. Но это в предположении, что не вся команда одновременно ленится. На ежедневном митинге, если видно что человек не укладывается в командную оценку, то он объясняет какие есть сложности. Если у техлида или кого-то другого есть подозрение на лень, то он может просто предложить доделать задачу в паре. А а в паре лениться гораздо сложнее.
Вы упускаете важную вещь — технический долг. И это задача тимлида донести до владельцев необходимость реализации технического долга. Лучше всего это делать монотонным зачитыванием issue с техническим долгом и расписыванием последствий проблем от оных.
Заметим, обратное, программистов нужно принуждать к написанию issue про технический долг. А это трудно, ибо человек должен (фактически) признать «я тут написал какую-то неведомую херню, но теперь я знаю, как это написать чуть лучше и мне на это надо в три раза больше времени».
Заметим, обратное, программистов нужно принуждать к написанию issue про технический долг. А это трудно, ибо человек должен (фактически) признать «я тут написал какую-то неведомую херню, но теперь я знаю, как это написать чуть лучше и мне на это надо в три раза больше времени».
С техническим долгом могут помочь также статические анализаторы. Помимо отлавливания общих проблем в коде и агрегации результатов, они могут также обрабатывать архитектурные проблемы в виде todo специального типа. Но это предполагает, что все честные и, вставляя костыль, добавляют todo с описанием проблемы и рисков с ней связанных. Тогда статический анализатор сводит все воедино и некоторые даже считают технический долг по заданным параметрам, переводя его в человеко-часы и деньги.
У нас недавно было принято, что после code review, если есть мнение, что это «таки работает», но есть ощущение, что халтура, то это оформляется как технический долг и распределяется на равне с остальными issue (это было сделано в рамках борьбы с бесконечным пин-понгом при code review, который де-факто — рефакторинг до победного конца).
Я не знаю, будут ли у этого решения долгосрочные проблемы, но после явной формализации понятия «технический долг» и выделения на него некоторого числа ресурсов, мы получили более steady flow, то есть предсказуемую скорость разработки. При этом PO/lead может оценивать степень важности рефакторинга и решать объём того, сколько на какую компоненту выделяется времени. Это позволяет задвинуть вниз всё не важное (в т.ч. и его рефакторинг), при этом поддерживать важное на должном уровне.
Но, эта штука пока у нас работает несколько недель, точнее будет понятно через месяца два-три.
Я не знаю, будут ли у этого решения долгосрочные проблемы, но после явной формализации понятия «технический долг» и выделения на него некоторого числа ресурсов, мы получили более steady flow, то есть предсказуемую скорость разработки. При этом PO/lead может оценивать степень важности рефакторинга и решать объём того, сколько на какую компоненту выделяется времени. Это позволяет задвинуть вниз всё не важное (в т.ч. и его рефакторинг), при этом поддерживать важное на должном уровне.
Но, эта штука пока у нас работает несколько недель, точнее будет понятно через месяца два-три.
Это открывает врата соблазна всю халтуру списывать на технический долг, а соответственно разрешает делать халтуру в принципе. Если за этим не углядеть, то может быть пичалька…
Мораль сей басни такова: гибкая разработка — это круто, но каждому необходимо понимать, когда ней можно начинать пользоваться, а когда еще рано.
Только в вашем случае — «когда уже поздно». Если уж вы завели проект в такое болото, глупо пенять на скрам, что он вас по волшебству оттуда не вытащил.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Job Safety Driven Development