• Где мы взяли флакон?
    0
    В статье не хватает:

    Kanban от Дэвида Андерсона и иже с ним
    Flow от Дональда Рейнерстена
    RUP и SAFe (хаха)
    LeSS
    Оргуправленческого мышления от Щедровицкого
    Lean стартап и так далее от Эрика Райса
    UX (впрочем, как и в продукте флакона)
    Теории кооперативных игр
    Экстремального программирования

    Нужно еще 10 лет для расширения кругозора. Тогда может быть во флаконе появится что-то приличное.
  • Где мы взяли флакон?
    0
    > качество — это степень соответствия требованиям, вроде

    Философия хохочет над этим определением. Пирсиг не может сдержать улыбку.
  • Где мы взяли флакон?
    0
    Флакон business-programming.ru/articles/tasks

    Все это очень формально, очень хрупко и очень усложнено.
    В таком виде флакон не взлетит.
    Только в узком кругу контроль-фриков.
    Суровая правда жизни.
  • Манифест жёсткого программиста
    0
    На мои 11 тоже не ответил. Что уж тут 2…
  • Манифест жёсткого программиста
    0
    Ладно, если математику 9 класса считать матмоделью софта, то я рад за вас. Ваша жизнь удалась.
  • Манифест жёсткого программиста
    0
    Отвечу то же самое, что и предыдущему оратору. Рекомендую начать углубляться в детали и понизить градус абстракции. По вашим ответам невозможно создать процесс разработки. По манифесту выше это хотя бы возможно, но к сожалению процесс получится совершенно неудовлетворительным с самых разных точек зрения, потому что он будет подходить только для узкого круга задач.

    Автор упускает довольно много важных деталей разработки ПО:
    1 — высокую неопределенность
    2 — психологию пользователей, которые редко знают, чего хотят
    3 — сложность создания систем (особенно в группе, особенно в большой группе)
    4 — невозможность формализации системы. ТЕМ БОЛЕЕ на уровне матмодели.
    5 — экспериментальный характер процесса разработки.

    Основная задача — увеличить скорость накопления знаний. Это следует делать увеличением количества экспериментов, ускорением экспериментов и постоянным взаимодействием с пользователями системы. Agile хотя бы делает к этому шаг, автор текущей статьи отпрыгивает назад шагов на 15
  • Манифест жёсткого программиста
    0
    Я ждал автора, но что же. Эти ответы совершенно неудовлетворительные.
    1. Даже с ТЗ подавляющее большинство проектов получается с задержками по времени, с большим количеством багов и с 0 пользой для клиентов. ТЗ не является ответом
    2. У меня жена и двое детей. Иногда надо быстро, пока дети не проснулись.
    3. Что такое норма? Что такое технология? Что такое костыль? Пожалуйста, эти абстрактные ответы оставляйте при себе. Нормы не существует.
    9. Аналогии не всегда работают, не так ли?
    10. Это бывает только никогда. Вернее, только при разработке очень простых и понятных система. Например, сайта для индивидуального предпринимателя Иванова.

    Рекомендую начать углубляться в детали и понизить градус абстракции.
  • Манифест жёсткого программиста
    –2
    У меня очень много вопросов к этому манифесту. Так как izvolov активен в комментариях, я смиренно надеюсь, что он найдет время ответить на 11 простых вопросов, которые, вне всякого сомнения, прояснят глубину его мысли и дальность её полета.

    1. Почему концепция важнее новых требований? Откуда это следует? Создавая систему, мы постоянно ставим эксперименты, которые влияют на концепцию. И что такое концепция вообще в вашем определении?
    2. Почему качество важнее скорости?
    3. Делать как надо? Это как именно? Полагаясь на что? На интуицию? На звезды? На физику параллельной вселенной?
    4. Почему наивысшим приоритетом для нас является плодотворная и продуктивная работа программиста? А как же пользователи с их проблемами? Программист работает для себя или для пользователей?
    5. Какой уровень качества необходим? Кто это решает? Как именно?
    6. Как быть начинающим разработчикам? Они еще не профессионалы, как им работать вообще?
    7. Что такое качественный продукт?
    8. Для какого софта можно разработать матмодель? Что такое матмодель для игры Packman? Что такое матмодель для движка Habr?
    9. Почему мы должны ориентироваться на каски строителей и хирургов?
    10. Что такое хороший техпроцесс?
    11. КОНТРОЛЬНЫЙ: Что такое качество?


  • Манифест жёсткого программиста
    +1
    1. Создают продукты те, кто работает над ними
    2. Не создают продукты те, кто над ними не работает
    3. Работайте над продуктами
  • Agile умер, да здравствует… Agile
    +3
    Вас обманули, это не скрам. Это жопа.
  • Agile умер, да здравствует… Agile
    0
    Автор не прав и НЕ рубит фишку. Главная проблема внедрения agile не качество, а недоверие и нежеление людей меняться в целом. Новое любит 10% населения, остальные любят старое и привычное. Проблема качества в agile проектах стоит ничуть не более остро, чем во всех остальных проектах. Автоматизация используется во всех типах проектов и нормально помогает.

    Хватит уже поминать agile. У нас уже post-agile тут на острие. Scrum и иже с ними выходят из моды и завоевывают non-software deveopment команды. Сейчас модно говорить о трансформации всей компании, холократия там, плоские структуры, доверие, вот это вот все.
  • 43 полезных сервиса для управления проектами. Без эпитетов
    +1
    Ну тулов сотни, много кого забыли, прямо скажем :)
  • Блок-схема выбора оптимальной методологии разработки ПО
    +1
    Смешная диаграмма. Надеюсь, ей никто не воспользуется в жизни.
  • Гибкое управление проектами и продуктами
    0
    В оглавлении смешались и кони, и люди. Концепция книги пока выглядит крайне странной. С миру по нитке? Ну я не знаю. Русские термины выглядят забавно :)
  • Резюме программистов. Часть 2 (хорошие)
    0
    Графики очень странные и пожалуй бесполезные, что там по оси Y?

    профили на гитхабе и стэковерфлоу нормалек

    Короче так себе резюме мне кажется, не раскрывает картину.
  • Применение диаграммы Парето для анализа причин отставания от графика разработки
    0
    Зачем? :)
  • Применение диаграммы Парето для анализа причин отставания от графика разработки
    0
    >Но в такой случае для чего на проекте менеджер?!

    И в самом деле. Может быть они не нужны?

    >«20% усилий дают 80% результата, а остальные 80% усилий — лишь 20%»

    С чего вы взяли, что это применимо для разработки ПО?
  • Применение диаграммы Парето для анализа причин отставания от графика разработки
    0
    Да все эти проблемы есть в любом проекте. Анализ прямо скажем мало полезен такого рода. Выглядит как зря потраченное время. Тестировщики быстрее тестировать не начнут, в закрытых задачах практически всегда были и будут баги.
  • Применение диаграммы Парето для анализа причин отставания от графика разработки
    0
    Главный вопрос — что с этими проблемами делать-то?

    >1. Возникновение бага из-за недостатка времени на тестирование задачи;

    Как, интересно, это определилось? Тестировщики сказали, что было мало времени?

    > 2. Перерасход времени в связи с появлением багов при закрытии задачи;

    И дальше что?

    >3. Возникновение бага из-за невозможности тестирования фичи

    Замечательная формулировка. Сразу возникает образ функционала, который невозможно использовать. Зачем вообще делать фичи, которые нельзя протестировать? Как это понимать?
  • Agile Board. Как мы планируем в Яндекс.Картинках и как к этому пришли
    0
    Диаграмма гантта отвечает на вопрос, какие задачи в каких состояниях? Это два разных инструмента. Молоток нагляднее отвертки? Хмм…
  • Agile Board. Как мы планируем в Яндекс.Картинках и как к этому пришли
    0
    борд показывает данные в двух измерениях, в отличие от обычного списка. Это гораздо нагляднее. Кроме того, статусов может быть больше трех, тогда разница в визуализации работы очень заметна.
  • Agile Board. Как мы планируем в Яндекс.Картинках и как к этому пришли
    +2
    Можете пояснить мысль как-то подробнее? В чем проблема фильтра Agile Board?
  • Agile Board. Как мы планируем в Яндекс.Картинках и как к этому пришли
    +1
    Не смотрели на Targetprocess?
    www.targetprocess.com/product/
  • Agile Board. Как мы планируем в Яндекс.Картинках и как к этому пришли
    0
    Ну можно и в двух словах объяснить: он позволяет планировать и трекать, хорошо работает с большим объемом данных и имеет меньше ограничений. Но без деталей это как-то звучит не очень убедительно :)

  • Agile Board. Как мы планируем в Яндекс.Картинках и как к этому пришли
    0
    Трелло хорош, но для больших команд не подходит

    medium.com/the-content-factory/e8eb96d7a701
  • ТОП-100 Аджайл книг всех времен (на конец 2013 года)
    +3
    Ааа, забыли самую лучшую книжку коберна, www.amazon.com/Agile-Software-Development-Cooperative-Edition/dp/0321482751
  • Визуальные спецификации
    0
    Я не согласен по всем пунктам.
    1 — детальный дизайн не лучше скетча во многих случаях, если уже есть дизайн всех готовых компонент. В этом случае, например, скетча более чем достаточно. И так ясно, где какая компонента будет. Думаю, таких случаев можно придумать еще

    2 — Хорошее решение любой более-менее сложной проблемы невозможно придумать за 2 недели. Точка. Понятно, что форму логина можно придумать за час. Таймлайны в Targetprocess можно придумать за месяца 2 при достаточно интенсивной работе. 9 женщин не могут родить ребенка за месяц. С проектирование часто тоже так.

    3 — Ничего не теряется. Надо просто правильно организовать процесс. И на выходе говно тоже зависит полностью от процесса и людей, которые в этом участвуют. Никаких принуждений не нужно. Нужно вовлекать в процесс всех на ранних стадиях и все будет хорошо.
  • Визуальные спецификации
    0
    1 — разработка ПО и строительство моста вещи довольно разные. Если для моста нужны все детали и просчет, для ПО обычного этого не нужно. И время затраченное на такую проработку деталей будет потрачено впустую. Поэтому скетчи вполне могут стать частью спека.

    2 — хорошее решение невозможно придумать за 2 недели. Если перед спринтом нет ничего, а только юзер стори, то для любой мало-мальски сложной проблемы не будет сделано хорошее решение. Посредственные — сколько угодно. Хорошие решения требуют времени. После 10 лет в продукте мы пришли к тому, что фазы UX и разработки разделены. UX фаза длинная и обычно нужно десяток итераций, чтобы найти хорошее решение.

    3 — разбиение большой задачи на маленькие и решение каждой задачи в контексте спринта — плохая практика. Очень легко потом получить странный функционал, который нужно будет переделать. Гораздо эффективнее продумать важные кейсы заранее и придумать решение, которое будет элегантно решать большинство из них. Конечно, можно ошибиться с самими кейсами. Поэтому если знания в домене невелики, то лучше выпустить хоть что-то на рынок и собрать фидбек. Если знаний много — это не обязательно делать.
  • Визуальные спецификации
    0
    Это примерно пятый вариант.
  • Визуальные спецификации
    0
    Кто ж спорит. Графика + текст лучше и того, и другого по отдельности.
  • Визуальные спецификации
    0
    :)
  • Визуальные спецификации
    +2
    Я по обоим «спорным» вопросам согласен. Но определение Спецификация = BDD сценарии + дизайн — слишком узкое. Есть много способов, и эти два на мой взгляд не являются единственными.

    По поводу реализации и дизайна все зависит от обстоятельств. В идеальном мире у разработчиков есть все, что нужно перед началом работы. В реальном конечно же нет. Если есть возможность, надо приближаться к идеалу. Если нет, работать с имеющейся информацией. Мы тоже когда начинали v.3 не имели готового дизайна, а всего лишь общую идею с приличной глубиной проработки. Дизайн устаканивался несколько месяцев, и конечно вся команда работала над функционалом в это время. Просто потом было много переделок, но тут уж нужно решить, что важнее — деньги сэкономить или время.
  • Визуальные спецификации
    0
    Чотка
  • Визуальные спецификации
    +1
    Какая именно картинка?
  • Визуальные спецификации
    +2
    Мое мнение такое — спецификация должна описывать все детали реализации, иначе их придумает разработчик и часто придумает херню. Типа сообщение об ошибке «You can't do that». Как только начинается разработка — должна быть такая спецификация.

    Разработчики могут принимать участие в обсуждениях UX и конечных решениях, что у нас и происходит. Но фазы UX и разработки должны быть разделены.
  • Визуальные спецификации
    +3
    Конечно, все зависит от контекста. Тут контекст — веб приложение. Для описания алгоритмов может и BDD подойдет нормально.

    У нас большое количество автоматических тестов. Для них пишутся кейсы и они автоматизируются. Остальное exploratory тестирование в основном. Баланс примерно 4 разработчика на 1 тестировщика.

    Если статья спорная — это же прекрасно, есть о чем поговорить.
  • Система управления проектами вроде Jira, только чтобы «облачная» и до 5 пользователей бесплатно
    +1
    Вышла новая версия www.targetprocess.com/3 — все переделали.
  • Как работают создатели Pivotal Tracker… О разработке, управлении и найме людей
    +6
    Мы пробовали нанимать на работу людей через парное программирование. Попробовали на человеках 10 где-то. Отказались. Причина проста — довольно сложно сразу человеку въехать в проект и делать там что-то серьезное. Не у всех есть навыки парного программирования, а без опыта можно и растеряться особенно в незнакомой среде. Решать тривиальные задачи в паре чтобы проверить коммуникацию? Ну это не сильно эффективно.

    У нас тоже два дня. Первый день разговор на 30 минут и тестовое задание на архитектуру на 2 часа — проверка на профпригодность.
    Если все ОК, то второй день глубокое интервью на 2-2.5 часа по разным темам.

    Ошибаемся мы очень редко. Может быть пропускаем хороших кандидатов, это да. Но из пары десятков человек, которых взяли, уволили только одного.
  • Особенности русской разработки
    0
    Вам не повезло. У нас есть такие девушки-программистки высокого уровня
  • Резюме программистов. Часть 2 (хорошие)
    0
    Я не HR к счастью :)
    Опыт работы отлично описан
    Специализация и профессиональные навыки — ну тут можно лучше структурировать наверное, хотя бы переносы строк между разделами вставить.
    Можно еще добавить любимые книги по специальности, в моем круге вроде это легко делается. Пройденные курсы (если есть). Раз вы говорите «Постоянно повышаю свою квалификацию», то хотелось бы увидеть подтверждение.