Comments 87
Я, когда читаю такие посты, сначала проникаюсь, представляю, как люди здорово работают, как у них все налажено так, что ничто не может пробить их отказоустойчивый процесс разработки, как им легко и спокойно работается в свое удовольствие. А потом, после минутных размышлений, неизменно прихожу к выводу, что если соблюдать все эти правила, добавить ко всему TDD, и еще и какую-нибудь agile практиковать, то когда же ж работать-то?! Никак не пойму, как же продукт движется, если все время уходит на саппорт процесса разработки.
Я вот только первые два пункта не нарушаю, остальные регулярно :(
Я вот только первые два пункта не нарушаю, остальные регулярно :(
Я так тоже думал.
Вы тратие на один час больше своего времени в краткосрочной перспективе. В долгосрочной экономите человеко-дни другим сотрудникам и себе (вас не дергают).
- Автоматизация: выкладок, бекапов, всего, что имеет смысл. Сначала кажется, что долго, а потом выясняется, что пара человеко-дней. Если над проектом работает пара десятков разработчиков, это экономит здесь час, там час, набегают дни и недели. Кроме этого, заваленные выкладки задерживают не только разработчика, но и тестировщиков и менеджеров.
- Если сложить это время, выясняется, что как раз на хот-пачти и и уходит все время. Обычно, принято считать, что полезна работа — это новые фичи, а не багфиксы и хотпатчи.
- Прерывания. Нет ничего хуже, чем когда «дергают». На то, чтобы вернуться обратно «в поток» тоже нужно время.
Вы тратие на один час больше своего времени в краткосрочной перспективе. В долгосрочной экономите человеко-дни другим сотрудникам и себе (вас не дергают).
После одного из факапов я собрал всех и задвинул тезис «всё, что может быть автоматизировано, должно быть автоматизировано». Помогло.
Правда, пришлось скрипты самому писать.
Правда, пришлось скрипты самому писать.
>пара человеко-дней
Вот вы и сами демонстрируете заголовок вашей статьи
Вот вы и сами демонстрируете заголовок вашей статьи
Я оценивал автоматизацию сборки и выкладки «абстрактного проекта в вакууме». Для больших и сложных систем это конечно займет больше времени. Я настраивал CI с нуля на четырех проектах, поэтому у меня уже есть некоторый опыт, чтобы говорить о таких сроках. Если тема настройки CI интересна, я могу написать tutorial на эту тему.
У меня всегда такие же мысли. Увы, реалии зачастую такие, что всю работу нужно было сделать еще вчера, поэтому писать тесты, чекать и т.п. и т.д. тупо некогда. И зависит это не всегда от разработчика, ибо его ставят тупо перед фактом необходимости сдать все через час-два.
Поверьте, это у вас в голове. Не надо писать тесты на краткосрочных проектах. Это не рентабельно. Если ваше приложение будет работать достаточно долго, вы просто сами выроете себе могилу «сделай за час-два». Потом все-равно кому-то придется переписывать приложение с нуля, потому что ни один здравомыслящий подрядчик не возьмется разгребать такой код. Современный IT-рынок — рынок соискателя, а не работодателя. Вы в праве и должны организовывать эффективный процесс разработки.
Точно так же не рентабельно делать все красиво и правильно на тысячу, когда бюджета выделили сто рублей (а под «сделать за час-два» подразумевается обычно именно это).
Я не спорю с тем, что Вы правы в целом, безусловно. Просто ситуации бывают разные и люди бывают разные. На это и хотел обратить внимание )
Я не спорю с тем, что Вы правы в целом, безусловно. Просто ситуации бывают разные и люди бывают разные. На это и хотел обратить внимание )
Разработчику в наше время не так уж и тяжело поменять работу. Если менеджер/заказчик лезет в разработку, и рассказывает вам как делать Вашу работу — это очень плохо.
Хм. Ну вообще-то на работу как раз больше времени остается. Все agile практики вообще-то направлены на минимальный уровень бюрократии и деланье того что нужно СЕЙЧАС. Если надо сейчас править баги то и правиш прямо сейчас (замечательное правило что баги со скрамборда всегда берутся первыми). Если нужен рефакторинг — рефакториш сейчас (а это из TDD). А вот запуски приложения и smoke-тестирование (это как раз и прогон минимально осмыслленого сценария на задеплоеном приложение) спасает огромное количество времени и вам и другим членам команды. По личному опыту — при процессе построенном по agile методологиям код реализующий нужную функциональность пишется куда быстрее.
Да, если всё это собрать вместе, то при изменении одного фрагмента кода, нужно будет подготавливать весь проект к этому как минимум три дня. Хотя… может это и не так много против того, что можно неделями ошибки выгребать потом.
>> никогда не отступать от этих правил.
а вот это зло.
Простейший пример, недавно(в начале весны) в воскресенье америка время двигала, а в РФ время уже не переводится. У нас и попадали сервера с фейсбуком связанные. Это было толи ночь толи утро нерабочего дня. Узнали об этом программисты благодаря экстренному смс уведомлению о проблемах на серверах. И фиксили прямо на продакшене. И пофиксили. Менеджмент и тестеры и вообще все остальные узнали о результатах в понедельник. Да это форс мажор, да это не часто происходит. Но, блин, на достаточно больших проектах разнесённых по многим странам такое бывает. И когда сервис лежит, хуже уже не сделаешь. И в этот момент нет никаких правил. Мотивированные люди сами знают что они могут делать всё для решения проблемы и решают её. Поэтому никогда не говори никогда. Я к тому что используя наборы правил, а этот набор достаточно хорош, надо знать и границы их применения и в определённые моменты отбросить и погрузиться в ничем не ограниченный цифровой драйв, который позволит в кратчайшие сроки делать то что обычно кажется невозможным.
а вот это зло.
Простейший пример, недавно(в начале весны) в воскресенье америка время двигала, а в РФ время уже не переводится. У нас и попадали сервера с фейсбуком связанные. Это было толи ночь толи утро нерабочего дня. Узнали об этом программисты благодаря экстренному смс уведомлению о проблемах на серверах. И фиксили прямо на продакшене. И пофиксили. Менеджмент и тестеры и вообще все остальные узнали о результатах в понедельник. Да это форс мажор, да это не часто происходит. Но, блин, на достаточно больших проектах разнесённых по многим странам такое бывает. И когда сервис лежит, хуже уже не сделаешь. И в этот момент нет никаких правил. Мотивированные люди сами знают что они могут делать всё для решения проблемы и решают её. Поэтому никогда не говори никогда. Я к тому что используя наборы правил, а этот набор достаточно хорош, надо знать и границы их применения и в определённые моменты отбросить и погрузиться в ничем не ограниченный цифровой драйв, который позволит в кратчайшие сроки делать то что обычно кажется невозможным.
Это правила «мирного времени». Если продакшн лежит — это другое. Естественно, что в этом случае нужно поднимать продакшн.
Вот, а в статье про это не написали. Именно правила мирного времени. И это надо помнить.
Я не знаю ни одного человека, который сказал бы «наши корпоративные стандарты запрещают поднимать приложение». По крайней мере, я бы не стал работать с таким человеком. А вот примеров «хоп-хоп, ща сделаю» у меня целый вагон.
Соблюдение правил «мирного времени» — позволяет избежать военного. Грубо говоря — чем больше кода у вас реально проверяется на тестовом стенде, чем ближе тестовая среда к «боевой» (и так далее по тексту) — тем меньше вероятность что на продакшене что-то пойдёт не так.
И когда сервис лежит, хуже уже не сделаешь
Можно случайно стереть всю БД из-за неправильного запроса))
Можно. И можно сделать бюрократию на доступ к боевым серверам. Можно слить конфиг на тестовый и работать на нём. Меньше риска меньше скорость. Это выбор который мы делаем. Есть бекапы и репликация. Это выбор в, в данном случае, того кто фиксит. На его усмотрение. И чем меньше стоит между ним и сервером тем лучше, а он уж в праве выбирать путь. Опять же это работает только в случае высоко профессионального и мотивированного персонала.
Я вот раньше думал — какие все вокруг замечательные профессионалы! И тесты пишут на каждый чих и в проблемы вдумываются и всегда в график попадают и не забывают нас, нубов, научить. Когда же я научусь так?
А потом уже сам поработал и повыпускал. Cвоими глазами увидел исходники многих знаменитых и коммерчески успешных продуктов, всех этих гениев клавиатуры… Когда б вы знали из какого сора растут стихи не ведая стыда :)
В общем, не нужно принимать все близко к сердцу. Идеальная разработка — это сны о чем-то бОльшем и не более того :)
А потом уже сам поработал и повыпускал. Cвоими глазами увидел исходники многих знаменитых и коммерчески успешных продуктов, всех этих гениев клавиатуры… Когда б вы знали из какого сора растут стихи не ведая стыда :)
В общем, не нужно принимать все близко к сердцу. Идеальная разработка — это сны о чем-то бОльшем и не более того :)
Я когда такие статьи читаю, мне идеальная разработка представляется как этакая религия. Есть заповеди, есть библии, есть апостолы и толкователи, попы и священники, есть церковь, при этом от верующего требуется «самодисциплина» и «самовоздержание» взамен на обещание райской загробной жизни; и смертные грехи, за которые попадаешь в ад, который кстати тоже есть.
И, так же как с религиями, даже самые святые попы не без греха, а люди, которые не отягощают себя излишней божественной моралью, достигают большего в жизни
Так что имейте веру и кайтесь ибодень суда релиз близок, либо идите пишите код, @#$%ь
Аминь
И, так же как с религиями, даже самые святые попы не без греха, а люди, которые не отягощают себя излишней божественной моралью, достигают большего в жизни
Так что имейте веру и кайтесь ибо
Аминь
Самодисциплина — да, религия — нет. Воздержание — вообще нет. Я писал не о процессе разработки, а о личной ответственности, мотивации разработчика и об уважении к другим членам команды. Какие чувства вы испытываете, если после апдейта из VCS проект не собирается или даже не стартует? А если коллега говорит, что исправил баг, вы заходите на главную страницу и видите там Exception?
UFO just landed and posted this here
> Значит, для выкладки на продакшн, я закладываю 3 часа времени.
Нет, значит выкладку на продакшн вы переносите на понедельник :) Никогда не планируйте релизов на пятницу, даже на утро.
Нет, значит выкладку на продакшн вы переносите на понедельник :) Никогда не планируйте релизов на пятницу, даже на утро.
Мне тоже больше нравится выкладываться по понедельникам.
И упаси вас Бог релизиться в конце года, числа эдак 28-29 декабря… :)
Нет, значит выкладку на продакшн вы переносите на понедельник :) Никогда не планируйте релизов на пятницу, даже на утро.
А в понедельник пара тысяч сотрудников приходят на работу, а у них ничего не работает начиная от электронных пропусков и заканчивая 42-координатными сверхсовременными станками.
Далеко не все можно релизить тогда, когда хочется девелоперам и менеджерам девелоперов. Иногда бывает совершенно наоборот и релизы допустимы, например, только в 18-00 пятницы, чтобы в случае форс мажора было 2 дня на откат и/или восстановление системы и вытекает такой график политики релизов из решаемых системой бизнес-задач.
> А в понедельник пара тысяч сотрудников приходят на работу, а у них ничего не работает начиная от электронных пропусков и заканчивая 42-координатными сверхсовременными станками.
Альтернатива — все выходные ничего не работает, и разработчики все выходные матерясь откатывают релиз и разбирают что же случилось.
А тестирование и стенд вам для чего? :)
> чтобы в случае форс мажора было 2 дня на откат и/или восстановление системы
Не исключаю и такое, если в выходные продакшн совсем никому не нужен, и можно спокойно накатить и потестить на продакшне.
Альтернатива — все выходные ничего не работает, и разработчики все выходные матерясь откатывают релиз и разбирают что же случилось.
А тестирование и стенд вам для чего? :)
> чтобы в случае форс мажора было 2 дня на откат и/или восстановление системы
Не исключаю и такое, если в выходные продакшн совсем никому не нужен, и можно спокойно накатить и потестить на продакшне.
А тестирование и стенд вам для чего? :)
А тестовый стенд всегда меньше боевой системы. По этому я склонен верить Законам Мерфи, согласно которым всегда может найтись баг, который не проявляется на тестовой системе, но расцветает во всей красе на боевой. :)
Альтернатива — все выходные ничего не работает, и разработчики все выходные матерясь откатывают релиз и разбирают что же случилось.
Альтернатива — это наличие политики выкатывания релизов, которая вытекает из решаемых бизнес-требований. Правда такая политика должна быть не только технической, но и организационно-правовой, ибо переработки оплачиваются по двойному тарифу и прочие сопутствующие вещи типа организации допуска в офис в выходные и т.д. тоже должны быть отработаны.
У нас это правило прописано в регламенте, так же прекращается релиз новых версий за две недели до нового года.
Лучше выкладывать в четверг, тогда будет день реальной работы и два выходных на исправление страшных ошибок. Или два выходных для обкатки заказчиком.
Многие случаи, это не оптимизм, а халатность скорее. Встречается регулярно, если с таким поведением не бороться — это становится нормой и укореняется. Я может поспорил бы только о юнит-тестировании каждого чиха. Но это вопрос скорее философский. :)
Я вот все никак не возьму в толк (уже не в первом топике), о каком-таком «откате» структуры БД (и уж тем более — о каком восстановлении БД из бэкапа) после релиза идет речь? Объясните, пожалуйста, как это все возможно, если данные пишутся в базу постоянно, машин много, а сайт нельзя останавливать даже на 10 секунд.
Если изменился только код — то ради бога, можно откатывать-накатывать хоть до ночи. Но релиз — не релиз, если в нем не меняется база. Мне за 15 лет ни разу не приходилось сталкиваться с необходимостью что-то «откатывать» на продакшене. Как это бывает у других? Каков процесс? Почему вообще возникает необходимость откатывать базу и что под этим подразумевается? Почему вначале не протестировать, успешно ли накатывается база, на тестовом кластере со свежезалитой копией всех данных продакшена (или хотя бы с частью данных, достаточно однородной)?
Если изменился только код — то ради бога, можно откатывать-накатывать хоть до ночи. Но релиз — не релиз, если в нем не меняется база. Мне за 15 лет ни разу не приходилось сталкиваться с необходимостью что-то «откатывать» на продакшене. Как это бывает у других? Каков процесс? Почему вообще возникает необходимость откатывать базу и что под этим подразумевается? Почему вначале не протестировать, успешно ли накатывается база, на тестовом кластере со свежезалитой копией всех данных продакшена (или хотя бы с частью данных, достаточно однородной)?
У нас база бекаптися просто мейнтененс-планом + бекапы инстансов амазона. Необходимости откатывать БД на демо-стенде не было, но в случае чего есть 2 варианта отката. Откат удобен в случае неудачного обновления дев/тест-окружения. На них актуальность данных не так важна, а вероятность накатить фигню существует. Существуют системы, в которых запись производится гораздо реже, чем раз в 10 секунд. Зависит от приложения.
Например, новая версия приложения требует альтера на базу (ну или еще какого изменения структуры/данных).
Проальтерили, обновили приложение — не взлетело. А старая версия кода с новой структурой БД не работает.
Вот и приходится «откатывать» структуру, т.е. применять обратный альтер.
Проальтерили, обновили приложение — не взлетело. А старая версия кода с новой структурой БД не работает.
Вот и приходится «откатывать» структуру, т.е. применять обратный альтер.
Был недавно на яндекс-субботнике, рассказывали про яндекс-диск. Так они там не структуру откатывают, а пишут патчи к старому коду, чтобы он поддерживал новую версию БД.
Я что ли один тут пессимист? Мне всегда кажется что мы ничего не успеем, всё делаем медленно, большую часть времени закладываю на написание тестов, отладку и ввод в эксплуатацию. Пессимизм видимо начинает резко проявлятся, когда начинаешь отвечать за других программистов-оптимистов, не иначе.
Вы же не задумываетесь, почему чистите зубы и умываетесь каждый день.
… вы серъёзно? Не чищу зубы несколько лет.
… вы серъёзно? Не чищу зубы несколько лет.
Гы. Комикс по нашей с другом цитате. Ностальгичненько.
Забавная презентация почти в тему: Optimistic Developers vs Pessimistic Testers
Еще полезно вводить мораторий на релизы, мержи (и любые другие изменения в продакшене) в определенные дни. Скажем по пятницам, последние дни месяца, за 2 дня до праздников и так далее. Избавляет от геммороя в выходные дни.
На прошлой YAC был доклад от Google «Тестирование 2.0». Доклад ни о чем, зато слайды смешные.
Докладчик: «В чем корень всех зол и багов?».
Перелистывает слайд: «Fridays».
Перелистывает слайд «Friday 17:00»
Докладчик: «Серьезно, может вообще запретить комиты по пятницам? Как это происходит? Вы уже спишите к друзьям, девушке. Думаете о чем угодно, но не коде»
Докладчик: «В чем корень всех зол и багов?».
Перелистывает слайд: «Fridays».
Перелистывает слайд «Friday 17:00»
Докладчик: «Серьезно, может вообще запретить комиты по пятницам? Как это происходит? Вы уже спишите к друзьям, девушке. Думаете о чем угодно, но не коде»
К сожалению, очень часто сопутствующими чертами оптимизма являются полное отсутствие критики и самокритики.
Поэтому все радастна идут ногавно гу со временем.
Ох (: хочется высказаться по поводу сроков.
Это, конечно, хорошо отстаивать сроки, но практика показывает, что если вы что-то делаете неделю — это не значит, что вы не можете сделать это быстрее. Поэтому прежде чем тупо упираться в свои представления сроков, хорошенько подумайте и оцените как условия, так и возможности.
Это, конечно, хорошо отстаивать сроки, но практика показывает, что если вы что-то делаете неделю — это не значит, что вы не можете сделать это быстрее. Поэтому прежде чем тупо упираться в свои представления сроков, хорошенько подумайте и оцените как условия, так и возможности.
Речь идет о зафиксированном объеме работ. Вы правы, что любая задача может иметь «full-banana» и «limited» реализацию. Например, «необходимо отображать на сайте документы для скачивания». Можно начать городить API, забирать эти ссылки через API от источников этих документов, поддерживать авто-обновление и еще много чего, а можно просто собрать необходимый список, положить эти документы на сервер со статикой и дать ссылки. Для конечного пользователя результат одинаков.
Всегда существует объем технического долга. Вопрос в том, на сколько этот технических долг критичен. Недопустимо мириться с костылями в «ядре» системы и core-функционале. Я работал с несколькими проектами, в которых основная бизнес-логика была написана «на костылях». Такой подход приводит к чудовищному перерасходу средств и такому-же чудовищному качеству продукта в среднесрочной и долгосрочной перспективах. Я сталкивался и продолжаю сталкиваться с менеджерами, которые убеждают меня, что поменять какое-то бизнес-правило, лежащее в основе приложения, — дело пяти минут.
Функционал, который делается для ограниченного количества пользователей, не является основным, и, возможно, в будущем, вообще не понадобится — совершенно другая история. Такой функционал я всегда предлагаю реализовывать «limited»-вариантом.
Всегда существует объем технического долга. Вопрос в том, на сколько этот технических долг критичен. Недопустимо мириться с костылями в «ядре» системы и core-функционале. Я работал с несколькими проектами, в которых основная бизнес-логика была написана «на костылях». Такой подход приводит к чудовищному перерасходу средств и такому-же чудовищному качеству продукта в среднесрочной и долгосрочной перспективах. Я сталкивался и продолжаю сталкиваться с менеджерами, которые убеждают меня, что поменять какое-то бизнес-правило, лежащее в основе приложения, — дело пяти минут.
Функционал, который делается для ограниченного количества пользователей, не является основным, и, возможно, в будущем, вообще не понадобится — совершенно другая история. Такой функционал я всегда предлагаю реализовывать «limited»-вариантом.
С вами согласен.
Но хочется поделиться личным опытом: участвовал я в проекте, в котором на «каждый функционал» отдавалось столько времени, сколько нужно разработчикам. В итоге всё равно получилась система с костылями (тут в тему будет картинка «Уж в этот раз я всё сделаю правильно»).
Зная о таком положении дел, менеджеру очень трудно согласиться дать больше времени. Этому надо учиться (:
p.s. Спасибо за статью!
Но хочется поделиться личным опытом: участвовал я в проекте, в котором на «каждый функционал» отдавалось столько времени, сколько нужно разработчикам. В итоге всё равно получилась система с костылями (тут в тему будет картинка «Уж в этот раз я всё сделаю правильно»).
Зная о таком положении дел, менеджеру очень трудно согласиться дать больше времени. Этому надо учиться (:
p.s. Спасибо за статью!
Мне подобные статьи напоминают советы в женских журналах, которые иногда читает моя жена, цитируя мне некоторые ради «чисто поржать». Суть в том, что там в КАЖДОМ номере рассказывают, какие надо делать упражнения, косметические процедуры ну и остальное чего там женщины делают. И всё это нужно делать обязательно, каждый день. Понимает ли журнал, что если женщина будет делать каждый день всё то, что написано хотя бы в 5-ти номерах подряд, то это будет занимать примерно 40-50 часов в сутки? А если взять журналы за пару лет — то и все 500 часов в день. А журналам пофиг на реальность — они рекомендуют «делать правильно». Так и вот эта статья — всё круто, если бы время было безразмерно, а понятия дедлайнов не существовало в принципе. А так — фантастика да и только.
А можно более подробно, что из вышеописанного займет у вас 40-50 часов в сутки? Может быть вы пользуетесь инструментами, которые вам не подходят и работают слишком долго?
Вы же призываете писать тесты: habrahabr.ru/company/infopulse/blog/177581/ и пишите о том, как отстаивать сроки: habrahabr.ru/company/infopulse/blog/170777/. Я не понимаю, в чем наши позиции расходятся.
Вы же призываете писать тесты: habrahabr.ru/company/infopulse/blog/177581/ и пишите о том, как отстаивать сроки: habrahabr.ru/company/infopulse/blog/170777/. Я не понимаю, в чем наши позиции расходятся.
Они схожи даже более, чем Вы указали. Я, к примеру, еще год назад писал об оптимизме программистов. Разница вот в этом:
и
Говорить «никогда» — это всегда резко, поспешно и, как любое общее и категоричное утверждение — неверно. И сложные задачи — тоже существуют. И они порой заставляют идти против своих же правил. В общем, у Вас хорошие и правильные мысли, я согласен со многими из них (в той же мере как читательницы женских журналов согласны с их советами), просто следовать им всегда и на 100% — слишком накладно и не приносит того профита, как «следовать на 80% и быть гибким в оставшихся 20%».
«поэтому я стараюсь никогда не отступать от этих правил»
и
«Я знаю, что не существует «слишком сложных» задач»
Говорить «никогда» — это всегда резко, поспешно и, как любое общее и категоричное утверждение — неверно. И сложные задачи — тоже существуют. И они порой заставляют идти против своих же правил. В общем, у Вас хорошие и правильные мысли, я согласен со многими из них (в той же мере как читательницы женских журналов согласны с их советами), просто следовать им всегда и на 100% — слишком накладно и не приносит того профита, как «следовать на 80% и быть гибким в оставшихся 20%».
Опытный разработчик сам знает, где он пойдет на компромисс, но это все-таки исключения, вроде уже подмеченного «упавшего продакшна». К сожалению, слишком много людей с которыми я работал «гибки» на 90%. Отсюда и категоричность.
Мне нравится одна фраза, которая описывает, как разные люди видят definition of done:
Я думаю, что «помыть посуду» — это включить воду и вымыть все, что есть в раковине. Моя жена думает, что «помыть посуду» — это убрать грязные тарелки со стола, протереть стол, помыть посуду, протереть, поставить в сушилку, ложки убрать шкафчик.
В разработке тоже самое. Я за то чтобыломать меня делать работу полностью.
Мне нравится одна фраза, которая описывает, как разные люди видят definition of done:
Я думаю, что «помыть посуду» — это включить воду и вымыть все, что есть в раковине. Моя жена думает, что «помыть посуду» — это убрать грязные тарелки со стола, протереть стол, помыть посуду, протереть, поставить в сушилку, ложки убрать шкафчик.
В разработке тоже самое. Я за то чтобы
проблема в том, что 90% разработчиков считают себя опытными (а значит и вправе делать отступление от правил).
Поэтому такие решения должен принимать тимлид или лид. Если даже они не знают, чем отличается абстрактный класс от интерфейса©, то не поможет уже ничего.
Ну-ну. Для меня этот вопрос (отличие абстрактного класса от интерфейса) просто таки повод для смеха :). Потому что в последний раз мне его задавали при приёме на работу, где (как оказалось) всё было написано на друпал 6 (кто не вкурсе — фреймворк на функциях). А в другом месте «тимлид» решил выпендриться «в чем отличия версий ...» (принципиально не отвечаю на такие вопросы) — и сам же запутался.
Так что, приходится признать, что и многие тимлиды входят в те 90%…
Так что, приходится признать, что и многие тимлиды входят в те 90%…
Как человек, очень часто задающий программистам вопрос «сколько на это времени нужно», могу сказать, что я куда спокойнее отнесусь к ситуации «обещал за 5, сделал за 2», чем «обещал за 2, а возится уже 5». Другими словами — единственный момент, когда программист может может выбрать положительную стратегию (всегда успевать) — это на этапе согласования сроков. В этот момент программист может возражать — и эти возражения будут услышаны. Всё последующее будет срыв сроков, «возиться» и «всё ещё не готово».
что, и никогда не задаёте вопросов «Сколько?! А чего так долго, там же только кнопку прикрутить?».
Как показывает практика, если программист знает, что втрое завысил сроки — он работает… Ну как бы это сказать — с ленцой («да там работы на 2 дня, а ещё неделя впереди»).
Как показывает практика, если программист знает, что втрое завысил сроки — он работает… Ну как бы это сказать — с ленцой («да там работы на 2 дня, а ещё неделя впереди»).
Программисты бывают разные (с).
Да, задаю. И программист должен объяснить где я ошибаюсь, потому что если у нас различается понимание состояния проекта, то это различие будет только нарастать.
Считать, что программисты всегда работают в поте лица своего — неправильно. Бывает — халтурят. Бывает — ленятся. Бывает, вообще пишут не то, что нужно, потому что не хотят вчитываться в мотивационную часть техзаания.
Считать, что программисты всегда работают в поте лица своего — неправильно. Бывает — халтурят. Бывает — ленятся. Бывает, вообще пишут не то, что нужно, потому что не хотят вчитываться в мотивационную часть техзаания.
А вам не кажется, что учёт рисков — это отнюдь не задача программиста? Т.е., да, программист может обьяснить, почему вот это — 2 попугая, а вот это 7. Но вот почему эти 2 попугая делались 3 недели…
Частично — программиста. Оценивая задачу, нужно думать не сколько займет времени сделать такую фичу в вакууме, но еще и
С такой оценкой менеджеру будет гораздо проще управлять рисками.
- Как эту фичу задеплоить
- Как внедрить ее в текущий функционал, нет ли сложностей
- Что потребуется менять во внутренней архитектуре, чтобы не оставлять тех. долг
- Можно ли сделать фичу быстрее, с учетом, что потом будет время на рефакторинг
- Какие есть внешние зависимости (например, внешние API), как быстро написать стабы на эти зависимости, если они не будут готовы в срок
С такой оценкой менеджеру будет гораздо проще управлять рисками.
Собственно это и будет оценка сложности задачи. (кроме последнего, т.к. сдавать задачу без проверки на реальных API — бессмысленно). Оценка же времени выполнения не должна лежать на программисте. Потому что кроме перечисленного Вами существует ещё:
1. Вероятность ухода программиста в отпуск/на больничный/увольнения
2. Вероятности появления срочных задач
3. Затраты времени на получение данных (от сторонних специалистов)
4. Общий отвлекающий «шум» (совещания, дни рождения, уровень шума в офисе)
Я уж молчу о том, что оценка будет зависить от настроения программиста.
В тоже время, большинство проблем повторяются постоянно (опять забыли, что нужно расширять функционал, полезла верстка, кто-то ушёл в отпуск, вылезли баги, устроили микрорефакторинг), и статистически неплохо ловятся. Поэтому я и считаю, что менеджеру проще оценить реальное время на написание задачи (если конечно он ведёт статистику, а не гоняется за программистом в последнюю минуту с криком «Сколько делать будешь?!»)
1. Вероятность ухода программиста в отпуск/на больничный/увольнения
2. Вероятности появления срочных задач
3. Затраты времени на получение данных (от сторонних специалистов)
4. Общий отвлекающий «шум» (совещания, дни рождения, уровень шума в офисе)
Я уж молчу о том, что оценка будет зависить от настроения программиста.
В тоже время, большинство проблем повторяются постоянно (опять забыли, что нужно расширять функционал, полезла верстка, кто-то ушёл в отпуск, вылезли баги, устроили микрорефакторинг), и статистически неплохо ловятся. Поэтому я и считаю, что менеджеру проще оценить реальное время на написание задачи (если конечно он ведёт статистику, а не гоняется за программистом в последнюю минуту с криком «Сколько делать будешь?!»)
Если программист не может (а точнее, не хочет) объяснить причины, то это нарушенное взаимодействие в команде и такой проект будет постоянно буксовать на мелочах. Обратная связь очень важна.
(из своего опыта)
Одну мелочь (которую я считал мелочью) программист начал делать. И делал, и делал, и делал. На вопрос «когда» отвечал «три часа осталось». На третью неделю я его растряс, выяснилось, что он пытается решить задачу невероятной сложности, практически не решаемую нашими силами, реализовать безумную логику, которая неявно вытекала из-за глупости в ТЗ, плюс изначальный подход к решению был выбран с небольшим запасом и этот «небольшой запас» кратно усложнил задачу.
После часа совместного изучения проблем ТЗ было переписано с нуля, значительно упрощено и выкинут нафиг весь запас по развитию архитектуры (потому что я знал, что никакого «развития» в этом месте не планируется).
Итог: программист дурак, что не сказал «это сложно сделать» и не сказал «упс, а тут, оказывается, сложно» вовремя.
Я дурак, потому что а) поверил программисту на этапе «на три часа осталось» б) тянул три недели а не полез разбираться в причинах после первых симптомов отставания.
Мораль: программист не просто должен, а обязан объяснять product owner'у и команде о возникающих у него проблемах и причинах, почему то или иное изменение на самом деле очень тяжёлое. Знание о цене реализации во-первых может вовремя поднять вопрос о рефакторинге кода, а во-вторых может вообще поменять стратегию реализации (например, «вместо фичи А будем делать Б»).
(из своего опыта)
Одну мелочь (которую я считал мелочью) программист начал делать. И делал, и делал, и делал. На вопрос «когда» отвечал «три часа осталось». На третью неделю я его растряс, выяснилось, что он пытается решить задачу невероятной сложности, практически не решаемую нашими силами, реализовать безумную логику, которая неявно вытекала из-за глупости в ТЗ, плюс изначальный подход к решению был выбран с небольшим запасом и этот «небольшой запас» кратно усложнил задачу.
После часа совместного изучения проблем ТЗ было переписано с нуля, значительно упрощено и выкинут нафиг весь запас по развитию архитектуры (потому что я знал, что никакого «развития» в этом месте не планируется).
Итог: программист дурак, что не сказал «это сложно сделать» и не сказал «упс, а тут, оказывается, сложно» вовремя.
Я дурак, потому что а) поверил программисту на этапе «на три часа осталось» б) тянул три недели а не полез разбираться в причинах после первых симптомов отставания.
Мораль: программист не просто должен, а обязан объяснять product owner'у и команде о возникающих у него проблемах и причинах, почему то или иное изменение на самом деле очень тяжёлое. Знание о цене реализации во-первых может вовремя поднять вопрос о рефакторинге кода, а во-вторых может вообще поменять стратегию реализации (например, «вместо фичи А будем делать Б»).
Ещё раз — программист может обьяснить сложность задачи, а не время на её исполнение. В вашем случае Ваша ошибка именно в том, что Вы слушали сколько времени осталось, а не забили тревогу, как только время на задачу весом в 2 попугая превысило среднестатистическое.
Так что дурак Вы в данном случае, и только Вы.
Так что дурак Вы в данном случае, и только Вы.
Что значит «объяснить время на её исполнение»?
Вы же понимаете, что я не могу над каждым программистом над его душой сидеть без устали. Более того, у меня есть вполне себе обратный пример — программист часто к концу спринта говорит «я всё закончил, что дальше»? (то есть берёт резерв спринта).
Если человек для проблемы недельного размера говорит «три часа осталось» — это нормально? На что я должен ориентироваться при оценке сложности и времени решения задачи?
Вы же понимаете, что я не могу над каждым программистом над его душой сидеть без устали. Более того, у меня есть вполне себе обратный пример — программист часто к концу спринта говорит «я всё закончил, что дальше»? (то есть берёт резерв спринта).
Если человек для проблемы недельного размера говорит «три часа осталось» — это нормально? На что я должен ориентироваться при оценке сложности и времени решения задачи?
Так а зачем над душой стоять — у вас таск трекера нет? У меня в команде всё было очень просто — к концу дня смотрим на выгорание задач. И если задача, которая находится в активном статусе (в процессе) долго не хочет выгорать — начинаем разговор с разработчиком.
Более того, такой подход позволяет довольно быстро ловить проблемы. Если сегодня задача оценена в 2 попугая, и на завтра — она всё также осталась в сложности 2 попугая — значит либо программист ничего не делал, или его отвлекают постоянно (вполне реальная ситуация), или мы ошиблись с оценкой.
Более того, такой подход позволяет довольно быстро ловить проблемы. Если сегодня задача оценена в 2 попугая, и на завтра — она всё также осталась в сложности 2 попугая — значит либо программист ничего не делал, или его отвлекают постоянно (вполне реальная ситуация), или мы ошиблись с оценкой.
Я — пессимистичный разработчик. Всякий раз, когда менеджмент что-то обсуждает, я указываю, где именно и почему у нас будут проколы по срокам, фичам, стабильности и т.п. Очень часто я таким образом порчу радужную картину в верхах и нарушаю всеобщуюу идиллию и эйфорию в компании. Несмотря на то, что все мои замечания в конце концов оказываются верными, меня все равно не любят.
А мне говорили, что я желчный и нарушаю атмосферу в команде :)
шутки шутками, но на самом деле половина наших придирок реально только мешают. Часто на моей практике мои замечания оказывались вполне верными, но низковероятными, и мы тратили на обсуждение и реализацию низковероятностных вещей больше времени чем на высокоприоритетные. Так что для себя сейчас взял правило — если вероятность появления некой ситуации ниже некого порога и не может нарушить работоспособность системы в целом — забили, решим на уровне тех-поддержки.
шутки шутками, но на самом деле половина наших придирок реально только мешают. Часто на моей практике мои замечания оказывались вполне верными, но низковероятными, и мы тратили на обсуждение и реализацию низковероятностных вещей больше времени чем на высокоприоритетные. Так что для себя сейчас взял правило — если вероятность появления некой ситуации ниже некого порога и не может нарушить работоспособность системы в целом — забили, решим на уровне тех-поддержки.
Меня за это вообще уволили. Я даже сроки не обсуждал, просто указывал, что такая-то хотелка выходит за рамки современной компьютерной науки.
Не идите на поводу у менеджеров
Распечатать и в рамку.
Sign up to leave a comment.
Программисты-оптимисты