Pull to refresh

Comments 45

Не согласен с 4,5,6. Поясню:

4. Самое простое решение в программировании-зачастую просто хотфикс. Даже если он работает правильно, скорее всего он не идеально вписывается в архитектуру приложения и/или плохо написан. Вполне вероятно, что его потом бредет тяжело поддерживать. Стоит ли говорить, что если половина проекта состоит их таких костылей, то поддерживать его будет до крайности неприятно?

5. В любом, даже самом интересном проекте бывают скучные места. Если слишком долго ими занимаешься, то пропадает мотивация и увлеченность. Кроме того, существует целый класс людей, которые не могут долго заниматься неинтересной им в данный момент работой. Для того, чтобы они хорошо работали им надо периодически перескакивать с одной задачи на другую, желательно чтобы задачи были разного типа. Таких людей называют иррационалами.

6. Так же как и у вас, у меня этот пункт вытекает из 5.
4. Как вы сказали — «Даже если он работает правильно, скорее всего он не идеально вписывается в архитектуру приложения и/или плохо написан. Вполне вероятно, что его потом бредет тяжело поддерживать.»
Соответственно этот подход не решает задачу, так как оставляет работу незаконченной
5. Если принять во внимание пункт 3 то таких ситуаций возникать не должно. Доделал простую неинтересную задачу и переключился на интересную
6. Если переключаться между недоделанными задачами возникают дополнительные сложности

Спасибо за конструктивную критику!
Я считаю, что в программировании очень важно уметь качественно переключаться.
Я считаю, что может существовать атомарная задача, на решение которой может уйти 8 часов чистого времени.
Я считаю, что такая задача может быть неинтересной.
Я считаю, что заниматься столько времени неинтересной задачей глупо и контрпродуктивно.
Я считаю, что во время выполнения такой задачи весьма умно, правильно и полезно заняться чем-нибудь ещё.
Я иррационал.
Я программист тоже. Работаю в некоем варианте скрама.

Пожалуйста.
Ну отлично, так сделайте задачу и занимайтесь следующей.
Иначе вы теряете время на переключение и увеличиваете количество коммуникаций.
Вы правы, есть и психологический фактор — ваше мнение по поводу интересности задачи влияет на вашу продуктивность.
Вы можете поработать над своим мнением и поднять собственный профессионализм на новый уровень убрав эмоциональную окраску с решаемых задач.
Или тратить время на переключение между задачами.
Выбор за вами.
Правильно ли я вас понял, что вы выполняете с одинаковой эффективностью любую работу.
Правильно ли я понял, что вы не относитесь эмоционально ни к одной части своей работы?
Я так не могу—я люблю интересную и созидательную работу, а писать очевидные рутины мне скучно. Я вполне могу этим заниматься, но предпочту разнести такую работу на неделю, перемежая её чем-нибудь ещё. А на переключение я трачу мизер времени, я это хорошо умею.

Тем не менее, спасибо за ваше мнение и за конструктив!
Дело в том что на переключение время вы все равно тратите.
А я знаю много профессиональных программеров кому наплевать интересная задача или нет.
Надо значит надо — это работа и ее надо делать.
Если вы сможете этому научиться — будет еще одним вашим плюсом.
Я согласен с «надо значит надо». Но я по образованию психолог, и как психолог я не верю в эффективность безэмоционального подхода к работе. То есть человек, который относится к своей работе без эмоций не сделает её так же качественно, хорошо и быстро, как человек, которому данная задача нравится, интересна.

Зато да, он сделает её лучше, чем тот, кому задача неинтересна.

Поэтому я за разделение задач по интересам внутри команды.
Отлично, вы же сами предложили два варианта.
1. Дать задачу тому кому она более интересна
2. Как психолог вы наверное знаете что отношение субъективно. Посмотрите на задачу с другой точки зрения. Возможно вы найдете в ней что-то интересное.

Я еще могу предложить вариант — не беритесь за нее пока не решите что готовы.
Еще можете придумать?
Только пожалуйста, не усложняйте себе жизнь недоделанной работой.
Мы с вами очень разные люди. Я так упрощаю себе жизнь. Про субъективность-это просто слова. Есть задачи, которые просто неинтересны. Очень легко может сложиться ситуация, что кроме меня некому. И тут смотри по-другому, не смотри, а делать надо. В таких ситуациях я заставляю себя делать задачу, скажем 2 часа в день, а остальное время занимаюсь работой, которая мне больше по душе.
Я даже не против вашего подхода. И вы согласны что в нем есть недостатки.
Так может сойдемся на том что, если есть возможность, закончить задачу лучше сразу?
А по психологии действительно есть люди которые предпочитают дотащить сразу до финиша, а есть те кто делает это в несколько приемов.
Я отношу себя к тем кому проще сделать и забыть. И считаю что при этом потеряю меньше времени и меньше устану психологически.
Вы считаете наоборот.
Каждому свое, правда?
Я согласен, что задачу надо закончить. Я согласен, что если силы есть закончить и неприятия процесса нету — то лучше закончить сразу.
Ну а во всем остальном — просто есть два типа людей. Тут даже и договариваться, в общем-то не о чем )).

Считаю, что дискуссия прошла успешно.
А на вопросы заданные corker выше ответите? ;)
Перепутал, конечно же не corker, а asm0dey вопросы задавал.
По моему вопрос был риторический. Не правда ли?
Мне так не кажется. Давайте представим, что эти вопросы я задал вот тут. (чтоб не копипастить).
Если хотите услышать ответы, задавайте вопросы. А вы не копипастите, вы сделайте реюз :)
вы этим постом кому-то глаза попытались открыть? или какая цель преследовалась?
«все фигня — во как надо!» — странный подход, особенно учитывая набор «простых тезисов» (KISS, кстати, не всегда работает).
очевидно, что основополагающие принципы Agile — это вполне себе житейские мудрости, завернутые в красивую обертку. это нисколько не умоляет достоинств этих подходов.
По-моему, это совсем не agile. Agile--это гибкая разработка (как следует уже из названия), и его основная идея--уменьшение времени обратной связи между всеми участниками: заказчик-мэнеджмент (или product owner), мэнеджмент-программисты (итерации и ретроспективы итераций), программисты-тестеры, мэнеджмент-ТЗ (если есть--в agile может и не быть) и всевозможные комбинации.

А у вас, скорее, правила эффективного кодинга с поправкой на agile.
Если вы попробуете провести аналогии между теми умными словами что написали в комментарии и моими то увидите плотную взаимосвязь.
Хочу сказать что я ни сколько не против быстрой обратной связи, определения Done итераций и Flow диаграмм.
Часто люди просто не понимают что за этим стоят очень простые вещи.
Важно за всем этим арсеналом держать фокус на действительно важных вещах.
Если вы делаете скарм, но работа над ошибками (ретроспектива) формальность, то надо что-то делать.
Не знаком с Agile (в смысле ничего кроме постов на Хабре не читал), но есть возражения из практики:
1. Зачастую сейчас (а то и «вчера») надо несколько вещей делать.
2. Эффект оценить сложно, особенно если цели проекта сам заказчик не осознает и приоритетов не ставит, есть лишь список фич, которые он хочет. Разве что считать эффективность через время (вернее его оценку), потраченное на уменьшение списка на один пункт
4. Иногда лучше чуть усложнить подход, чем лишаться универсальности и других качеств, например, тестируемости, ради простого подхода, который чуть ли не априори создаст проблемы в будущем, например глобальные переменные.
5 и 6 — Выше сказали, что не всегда повышает продуктивность, даже учитывая потери времени на переключение контекста. Правда я бы большее значение отдал не интересности/скучности задачи, а зашориванию мозга в процессе длительной работы над одной, пускай даже интересной, задачей. Переключившись с неё на другую хотя бы на час (не говоря о том, чтоб продолжать на следующий день) можно при возврате увидеть новые подходы или просто очевидный при свежем взгляде баг. У человека (а программисты тоже люди, как ни странно :) ) кроме сознания, которое переключается, есть ещё и подсознание, работающее в фоне. Ждать пока оно выдаст что-то полезное непродуктивно, по-моему, а так «отправили запрос», переключились на другую задачу и ждём «ответа». Асинхронность — наше всё :)

Про 7 вообще не понял — это как в школе 10 раз один фрагмент переписывать с нуля, вырабатывая моторную и зрительную память?

С 3 согласен, но это уж совсем очевидное, даже в фольклоре зафиксировано — например: «Глаза боятся, а руки делают».
Это я писал про скучность/интересность и я согласен, что даже просто переключение внимания от интересной задачи может подсказать лучшее решение чем то, которое в данный момент планируешь реализовать. Тут у меня уже личная проблема — интересная задача меня поглощает настолько, что я могу по 12 часов забывать о еде. семье и вообще времени. И это при том, что работаю я дома.
Увлекающаяся натура…
1. Делайте их по очереди - будет меньше ошибок.
2. Здесь эффективность - сколько можно заработать на этой задаче. Также существует много практик приоритизации в сложных ситуациях.
4. Согласен. И не призываю скипать хорошие практики. Более того рекомендую включить требования по архитектуре и тестам в условия готовности задачи.
5 и 6 Дело ваше. Есть и плюсы и минусы. Выбирайте то что вам больше нравится. Для меня эффективнее доводить работу до конца не откладывая ничего на потом. Убедить мне вас теоретически не получится.
7. Оттачивайте мастерство разными способами - делайте ретроспективы, ревью кода, анализ багов, анализ архитектуры и т.п.

А с элементами аджайл вы сталкиваетесь в работе стопроцентно.
Просто вы не называете их таким словом. Потому что они тривиальны и не нуждаются в доказательствах.
Аджайл - модное слово, но в основе лежат как раз такие простые вещи которые я в статье и описал.

К сожалению ни Скрам ни ХР ни Канбан не говорят о них напрямую. Поэтому люди часто не замечают эти простые вещи за инструментами.
Но если пойти на тренинг к Асхату, Сазерленду или Книбергу вы стопроцентно услышите о них.
Можно еще проще: «do right things» но никак не «do things right»
Все-таки сильно упрощенно. Ваш agile можно применить почти к любой специалбности теперь
Ну так и заголовку соответствует же!
Кстати Сазерленд вообще Скрам в церкви применяет :)
Вы хорошо сравнили Agile с бухгалтерией. Бухгалтерия почему из простой вещи превратилась в то, чем она есть сейчас? Для того, чтобы не нужно было думать головой, что и куда писать. Достаточно взять инструкцию, в которой написано «взято цифру из столбика А, умножить на 1.5, добавить к столбику Б и записать результат в столбик С» — и всё! Можно брать девочку с улицы, 2 дня на тренировку — и дальше она будет клепать эти ведомости.

Так же и тут. Все Ваши 7 пунктов сводятся к одному — «думать головой». Вот только людей, которые умеют это делать мало, их не хватает нигде и в ИТ в том числе. Специально для этого придуманы все эти скрамы, канбаны и прочие вещи, однозначно инструктирующие руководителя и команду когда собираться, что и в каком порядке обсуждать, когда и как проверять результаты и т.д. Чем меньше приходится думать над такого рода вещами — тем больше времени остаётся на непосредственно работу. Когда-то изобретатель суперкомпьютера Крей приводил такой вот алгоритм выбора автомобиля: «Приходим в ближайший к дому автомагазин, покупаем ближайшую к дверям машину» — такого рода алгоритмы помогали ему тратить меньше времени на неважные вещи и больше — на важные. Так что алгоритмы скрама и канбана помогают меньше времени думать об организации работы и больше — над самой работой.
Дык я и не против, я-ж стараюсь думать научить. Объяснить откуда ноги растут.
Эйнштейн, говорят, имел 30 одинаковых костюмов, чтобы не тратить время на ежедневный выбор :)
Ну значит можете считать что этот твит для тех кто «думает головой» и как Энштейн задумывается о выборе того единственного костюма который будет носить потом всю жизнь.
У вас нет сведений костюм у него был куплен на распродаже или сшит по заказу лично для него?
Вроде в то время магазинов готового платья ещё не было (или они только появились)
Если статья понравилась, поднимите карму.
Автор, ты спецом прикалываешься? :)) Это не статья, а заметка в твитер.
Ну да - простое не должно быть сложным!
Вот это влезет в твит:

Agile — when all involved parties work together as a single person on a smallest most valuable task one by one with defined constant quality
Очень многие люди (как и я сам) не умеют доводить дела до конца. Поэтому и не понимают ценность этих простых 7 тезисов. Ибо тезисы не о конкретных вещах, а о подходе к работе, который позволит доводить все до конца. И, имхо, большинство рядовых нанимаемых сотрудников это никогда не поймут, ибо не сами расставляют приоритеты в своей работе.
Может хоть кому-то будет полезно и поможет вырасти профессионально.
Спасибо за поддержку!
Достали вы уже, защитники иконостасов.
Вместо того чтобы подумать хоть чуть-чуть, найти рациональное зерно молитесь своим богам и не видите леса за елками.
А потом спрашиваете, почему люди не принимают Аджайл?
Да потому что из манифеста и практик Скрама не очевидно что за этим стоит.
Я вам про опыт свой десятилетний, вообще-то довольно успешный, а вы мне про теорию и практики прошлого века.
Все новые методы разработки создаются потому, что их создатели в свое время плохо читали Брукса, его «Мифического человеко-месяца». Когда читал, поражался что эта книга написана 30 лет назад. Либо Брукс пророк, либо с тех пор в разработке ПО ничего не изменилось. А значит… «Серебренной пули не существует».
Хороших книг много. Но кто их читает? Мне еще нравится «Смертельный марш» Эдварда Йордана.
Интересная книжка, надо будет почитать.
Sign up to leave a comment.

Articles