Comments 42
Спольски долго бился головой о тяжелый, неудобный интерфейс FogBugz, и наконец написал свою Kanban доску? :)
Про мир Mac OS X улыбнуло:) Видимо, мы в каких-то разных мирах живем.
И да, новая версия операционной системы должна выходить раз в ~5-10 лет (как это происходит с виндой, линуксом и той же макосью), а не каждые полгода, как у андроида. Да, новые фичи надо выкатывать по мере реализации, но ни в коем случае не ломать совместимость с уже написанным софтом.
И да, новая версия операционной системы должна выходить раз в ~5-10 лет (как это происходит с виндой, линуксом и той же макосью), а не каждые полгода, как у андроида. Да, новые фичи надо выкатывать по мере реализации, но ни в коем случае не ломать совместимость с уже написанным софтом.
вы удивитесь, но макось последняя вышла год назад, а новая будет в конце месяца. убунту релизится раз в полгода, но есть и вообще rolling-release.
Это в windows мире любят 5 лет заботливо что-то делать, а потом люди плюются, когда пересаживаются, потому что нифига не понятно.
Это в windows мире любят 5 лет заботливо что-то делать, а потом люди плюются, когда пересаживаются, потому что нифига не понятно.
Простите, а у какого конкретно дистрибутива Linux новая версия выходит раз в 5-6 лет?
Я про ядро, если кто не понял. Что там маркетологи на коробочке нарисовали — дело десятое, главное что софт не ломается.
Ядро и ОС, это разные вещи это раз.
Операционная система не определяется ядром. Это два.
Ядро линукса релизится куда чаще раза в 5 лет (минорные релизы), даже чаще релиза убунты. Это три.
Пользователю побоку, что там в ядре поменялось. Пользователю важно удобство. Это четыре
Операционная система не определяется ядром. Это два.
Ядро линукса релизится куда чаще раза в 5 лет (минорные релизы), даже чаще релиза убунты. Это три.
Пользователю побоку, что там в ядре поменялось. Пользователю важно удобство. Это четыре
Пользователю и особенно программисту не побоку, что на рынке присутствуют одновременно два-три поколения устройств с разными версиями ОС, которые не просто не совместимы между собой, но требуют рефакторинга приложений ради совместимости. Вот это — засада.
А то, что где-то что-то пропатчили или добавили финтифлюшечку в новом релизе — так это и под винду этих патчей иногда по нескольку штук в день выходит.
А то, что где-то что-то пропатчили или добавили финтифлюшечку в новом релизе — так это и под винду этих патчей иногда по нескольку штук в день выходит.
(первая часть про андроид была, если кто не понял)
расскажи пожалуйста про то, как не ломают совместимость в виндах. а то я везде слышал мнения другого толка.
может перейдем от слухов к фактам? Где что поломалось в винде скажем при переходе от 95 к 7, ну кроме пары недокументированных функций и прямого доступа к железу?
Зря вы так категорично. При всей моей симпатии к *nix-like, думаю, M$ таки тратит на поддержку обратной совместимости значительно больше всех остальных. Иногда доходя до абсурда, на мой взгляд, но это другой вопрос. Почитать можно на The old new things поискав по соответсвующим запросам.
Подсказки гугла при поиске joel spolsky жгут напалмом.
>Trello отлично работает с небольшим количеством запасов, но быстро становится громоздкой и неудобной, когда вы впихиваете в неё много лишнего. Это сделано намеренно.
Умные люди давно уже придумали ограничивать число задач, которые могут быть в определенной стадии. Нужен тупо физический блок. Это азы канбана.
А позволять делать, но так, чтобы это было неудобно — самая ужасная практика из всех возможных :)
Умные люди давно уже придумали ограничивать число задач, которые могут быть в определенной стадии. Нужен тупо физический блок. Это азы канбана.
А позволять делать, но так, чтобы это было неудобно — самая ужасная практика из всех возможных :)
Я в легком шоке от видео, хочу себе такое!
>Сразу отсеивайте ошибки, которые слишком незначительны, чтобы их записывать.
сомнительное какое-то предложение. Кто должен решать значительна ошибка или незначительна? Тестировщик? Пусть уж лучше она won't fix лежит и поиском находится, чем каждый раз на нее натыкаться и думать, надо ли ее фиксить или нет.
сомнительное какое-то предложение. Кто должен решать значительна ошибка или незначительна? Тестировщик? Пусть уж лучше она won't fix лежит и поиском находится, чем каждый раз на нее натыкаться и думать, надо ли ее фиксить или нет.
Сделайте поправку на категоричность суждений Спольски ;) Он, помнится, в книжке disclaimer писал.
В маленьких коммандах зачастую тестировщик он же кодер
В вашем опыте правда были проекты с несколькими тысячами багов, где баг, не помня его в прошлом, можно было найти поиском?
По-моему, это из области фантастики.
По-моему, это из области фантастики.
не вносите туда новых элементов, пока не реализуете старые
остановитесь и начните исправлять их, пока не доберётесь до
Тут есть серьезное противоречие с общим посылом «не останавливайтесь» и «не держите запасов». И вообще, не совсем в духе Спольски: не только хромающая логика, но и недоказанный и очевидно не универсальный подход «давайте побежим и трахнем вон ту коровку©».
остановитесь и начните исправлять их, пока не доберётесь до
Тут есть серьезное противоречие с общим посылом «не останавливайтесь» и «не держите запасов». И вообще, не совсем в духе Спольски: не только хромающая логика, но и недоказанный и очевидно не универсальный подход «давайте побежим и трахнем вон ту коровку©».
Согласна, инновационные идеи не допустим до обсуждения просто потому что у кого-то не было времени бэклог почистить? Просто систему приоритизации нужно хорошую. Есть классные штуки, которым можно поставить высокий приоритет, а есть не гениальные вещи, но зато легко реализуемые — их можно маркировать как easy win. И в зависимости от наличия времени/ресурсов вытаскивать из бэклога идеи согласно приоритетам.
Спольски почитал Голдратта?)
Такое ощущение, что Спольски активно ищет, но пока точно не знает, что ему надо.
Вот, к примеру, в продукте сразу же сами собой напрашиваются теги или категории (и они есть в планах). Маркировать шестью цветными меточками (пусть даже и именоваными) не очень наглядно. Свободно определяемые теги были бы удобнее. Приоритеты в каком-либо виде и фильтры по ним тоже не помешали бы
Я пока что так выкрутился — создал несколько пользователей с соответствующими аватарами, теперь у меня есть наглядные иконки (их можно объединять и по ним можно фильтровать, естественно):
Кроме того, подсознательно хочется привнести какие-то элементы GTD в этот канбан. Ну то есть ToDo — они ж бывают «Сделать сегодня» либо «На этой неделе», либо «когда-нибудь» и т.д. Вообще Спольски — весьма разумный, может ему удастся в конечном итоге сделать действительно удобную штуку. Да и то, что есть — уже вполне работоспособно. Когда он допилит приложение для андроида, будет совсем хорошо.
Вот, к примеру, в продукте сразу же сами собой напрашиваются теги или категории (и они есть в планах). Маркировать шестью цветными меточками (пусть даже и именоваными) не очень наглядно. Свободно определяемые теги были бы удобнее. Приоритеты в каком-либо виде и фильтры по ним тоже не помешали бы
Я пока что так выкрутился — создал несколько пользователей с соответствующими аватарами, теперь у меня есть наглядные иконки (их можно объединять и по ним можно фильтровать, естественно):
Кроме того, подсознательно хочется привнести какие-то элементы GTD в этот канбан. Ну то есть ToDo — они ж бывают «Сделать сегодня» либо «На этой неделе», либо «когда-нибудь» и т.д. Вообще Спольски — весьма разумный, может ему удастся в конечном итоге сделать действительно удобную штуку. Да и то, что есть — уже вполне работоспособно. Когда он допилит приложение для андроида, будет совсем хорошо.
Так вы ему пишите! Ж)
Так я у него уже проголосовал за полезные фенечки
«50-тонных силосов для хранения муки» — Видимо, в оригинале — silo либо silo tower? Силос в русском языке — это корм для скота, а silo tower — силосная башня, в данном тексте — элеватор.
>Каждый раз, когда кто-то предлагает безумную новую идею, вы смотрите в бэклог и, если там слишком много записей, не тратите время на обсуждение и обдумывание этой идеи.
Блин, ну почему всегда абстрактные предложения? Почему все эти рассуждения, выглядят как философия?
Покажите мне практический пример, как отключать себе мозг, чтобы «не тратите время на обдумывание этой идеи»?
Я не могу не думать над самыми разными задачами. Если кто-то высказал мысль, и если она здравая, то я не представляю себе, как отключиться и не думать о ней хоть какое-то время.
Единственный практический пример, который приходит, это убивать на месте того, кто зная о большом числе текущих обсуждений, позволил себе поселить в головах других, новую мысль. Тогда, зная о последствиях, народ будет заглядывать в список, прежде чем поселить в головах других, свои идеи… хотя конечно и это не всегда сработает)) (это прикол конечно...)
Блин, ну почему всегда абстрактные предложения? Почему все эти рассуждения, выглядят как философия?
Покажите мне практический пример, как отключать себе мозг, чтобы «не тратите время на обдумывание этой идеи»?
Я не могу не думать над самыми разными задачами. Если кто-то высказал мысль, и если она здравая, то я не представляю себе, как отключиться и не думать о ней хоть какое-то время.
Единственный практический пример, который приходит, это убивать на месте того, кто зная о большом числе текущих обсуждений, позволил себе поселить в головах других, новую мысль. Тогда, зная о последствиях, народ будет заглядывать в список, прежде чем поселить в головах других, свои идеи… хотя конечно и это не всегда сработает)) (это прикол конечно...)
1. Вырвано из контекста LEAN ( yandex.ru/yandsearch?text=LEAN&lr=10435 ) с минимальной адаптацией для ИТ
Также очень здорово прочитать «Цель» Голдратта
2. "Предложение: Не позволяйте бэклогу разрастаться больше чем на месяц-другой работы. Если бэклог полон, не вносите туда новых элементов, пока не реализуете старые. Не надо тратить время на обсуждение, проектирование или спецификации фич из бэклога. Он должен рассматриваться как список вещей, о которых запрещено говорить и над которыми запрещено работать до начала реализации."
Да вы с ума сошли, следующим предложением будет создать клон бэклога для более чем месяца-другого работы.
Вывод — надо правильно управлять бэклогом
3. "На то, чтобы собрать эти багрепорты, ушли месяцы и годы, и вы спрашиваете себя, как это вообще возможно — у нас 3000 ошибок, а продукт при этом очевидно очень хорош, пользователи любят его и пользуются им каждый день?"
Та же фигня, предложение все закрыть не канает. Важно понимать как вы управляете и как вы в рамках управления проводите проверку и воздействие (PDCA — Plan, Do, Check, Act).
4. «Фичи, ожидающие релиза. „
Очень специфично, для гугл хрома это вполне оправданно, и даже в случае выхода USB 4 отсутствие его оперативной поддержки для существующих операционных систем будет фейлом. А вот внедрение какой-нибудь релиционно СУБД ориентированной файловой системы вряд ли может делаться в минорном апдейте ввиду сложности новой технологии и изменения программного ландшафта для зависимых систем.
Короче, чувак рекламирует какой-то там софт…
Также очень здорово прочитать «Цель» Голдратта
2. "Предложение: Не позволяйте бэклогу разрастаться больше чем на месяц-другой работы. Если бэклог полон, не вносите туда новых элементов, пока не реализуете старые. Не надо тратить время на обсуждение, проектирование или спецификации фич из бэклога. Он должен рассматриваться как список вещей, о которых запрещено говорить и над которыми запрещено работать до начала реализации."
Да вы с ума сошли, следующим предложением будет создать клон бэклога для более чем месяца-другого работы.
Вывод — надо правильно управлять бэклогом
3. "На то, чтобы собрать эти багрепорты, ушли месяцы и годы, и вы спрашиваете себя, как это вообще возможно — у нас 3000 ошибок, а продукт при этом очевидно очень хорош, пользователи любят его и пользуются им каждый день?"
Та же фигня, предложение все закрыть не канает. Важно понимать как вы управляете и как вы в рамках управления проводите проверку и воздействие (PDCA — Plan, Do, Check, Act).
4. «Фичи, ожидающие релиза. „
Очень специфично, для гугл хрома это вполне оправданно, и даже в случае выхода USB 4 отсутствие его оперативной поддержки для существующих операционных систем будет фейлом. А вот внедрение какой-нибудь релиционно СУБД ориентированной файловой системы вряд ли может делаться в минорном апдейте ввиду сложности новой технологии и изменения программного ландшафта для зависимых систем.
Короче, чувак рекламирует какой-то там софт…
Как же Джоэль любит хлебобулочные ассоциации.
Напомнило
Напомнило
Rapid board'ы на гринхоппере в джире как раз об этом же и, на мой взгляд, намного удобнее.
«Так же как и кусочки теста...» — просто мосг взорвало.
Sign up to leave a comment.
Джоэль Спольски: производственные запасы в разработке ПО