• 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 к счастью :)
    Опыт работы отлично описан
    Специализация и профессиональные навыки — ну тут можно лучше структурировать наверное, хотя бы переносы строк между разделами вставить.
    Можно еще добавить любимые книги по специальности, в моем круге вроде это легко делается. Пройденные курсы (если есть). Раз вы говорите «Постоянно повышаю свою квалификацию», то хотелось бы увидеть подтверждение.
  • Резюме программистов. Часть 2 (хорошие)
    0
    Вроде вполне хорошее резюме на мой взгляд. Может быть смущает «Разработка серверной части веб-сайтов Python/C++», как-то уже не принято на С++ бэкэнд писать. На мой взгляд стэк технологий довольно своеобразный, но это понятно, так как была миграция из C++ разработчика в веб.

    Нигде не видно знания ООП/FP. Думаю, это подразумевается, но вдруг нет?

    Я бы вас позвал на интервью.
  • Резюме программистов. Часть 2 (хорошие)
    0
    Лови плюсик
  • Резюме программистов. Часть 2 (хорошие)
    0
    Ну да, если посылать забугор, то текст хреновый. У нас в беларуси как-то принято рассылать резюме на английском даже в местные компании. Наверное, это древняя традиция аутсорсинговых контор.
  • Резюме программистов. Часть 2 (хорошие)
    0
    А, ну тут же не нейтив спикеры живут. Нормально.
  • Резюме программистов. Часть 2 (хорошие)
    0
    какой кусок?
  • Резюме программистов. Часть 2 (хорошие)
    +1
    Ну пожалуй да, если человек за 3 года поменял 3 места — я спрашиваю почему
  • Резюме программистов. Часть 2 (хорошие)
    +1
    Мне не нравится, и я делаю все, чтобы они не уходили. Пока более-менее получается. Другие не делают — от них уходят. Это нормально.
  • Резюме программистов. Часть 2 (хорошие)
    0
    Ответ прост. en.wikipedia.org/wiki/Sturgeon's_Law
  • Резюме программистов. Часть 2 (хорошие)
    0
    Ну да, об этом даже книжки пишут. Thinking Fast and Slow, к примеру. Но это не мешает мне поражаться :)