борд показывает данные в двух измерениях, в отличие от обычного списка. Это гораздо нагляднее. Кроме того, статусов может быть больше трех, тогда разница в визуализации работы очень заметна.
Ну можно и в двух словах объяснить: он позволяет планировать и трекать, хорошо работает с большим объемом данных и имеет меньше ограничений. Но без деталей это как-то звучит не очень убедительно :)
Я не согласен по всем пунктам.
1 — детальный дизайн не лучше скетча во многих случаях, если уже есть дизайн всех готовых компонент. В этом случае, например, скетча более чем достаточно. И так ясно, где какая компонента будет. Думаю, таких случаев можно придумать еще
2 — Хорошее решение любой более-менее сложной проблемы невозможно придумать за 2 недели. Точка. Понятно, что форму логина можно придумать за час. Таймлайны в Targetprocess можно придумать за месяца 2 при достаточно интенсивной работе. 9 женщин не могут родить ребенка за месяц. С проектирование часто тоже так.
3 — Ничего не теряется. Надо просто правильно организовать процесс. И на выходе говно тоже зависит полностью от процесса и людей, которые в этом участвуют. Никаких принуждений не нужно. Нужно вовлекать в процесс всех на ранних стадиях и все будет хорошо.
1 — разработка ПО и строительство моста вещи довольно разные. Если для моста нужны все детали и просчет, для ПО обычного этого не нужно. И время затраченное на такую проработку деталей будет потрачено впустую. Поэтому скетчи вполне могут стать частью спека.
2 — хорошее решение невозможно придумать за 2 недели. Если перед спринтом нет ничего, а только юзер стори, то для любой мало-мальски сложной проблемы не будет сделано хорошее решение. Посредственные — сколько угодно. Хорошие решения требуют времени. После 10 лет в продукте мы пришли к тому, что фазы UX и разработки разделены. UX фаза длинная и обычно нужно десяток итераций, чтобы найти хорошее решение.
3 — разбиение большой задачи на маленькие и решение каждой задачи в контексте спринта — плохая практика. Очень легко потом получить странный функционал, который нужно будет переделать. Гораздо эффективнее продумать важные кейсы заранее и придумать решение, которое будет элегантно решать большинство из них. Конечно, можно ошибиться с самими кейсами. Поэтому если знания в домене невелики, то лучше выпустить хоть что-то на рынок и собрать фидбек. Если знаний много — это не обязательно делать.
Я по обоим «спорным» вопросам согласен. Но определение Спецификация = BDD сценарии + дизайн — слишком узкое. Есть много способов, и эти два на мой взгляд не являются единственными.
По поводу реализации и дизайна все зависит от обстоятельств. В идеальном мире у разработчиков есть все, что нужно перед началом работы. В реальном конечно же нет. Если есть возможность, надо приближаться к идеалу. Если нет, работать с имеющейся информацией. Мы тоже когда начинали v.3 не имели готового дизайна, а всего лишь общую идею с приличной глубиной проработки. Дизайн устаканивался несколько месяцев, и конечно вся команда работала над функционалом в это время. Просто потом было много переделок, но тут уж нужно решить, что важнее — деньги сэкономить или время.
Мое мнение такое — спецификация должна описывать все детали реализации, иначе их придумает разработчик и часто придумает херню. Типа сообщение об ошибке «You can't do that». Как только начинается разработка — должна быть такая спецификация.
Разработчики могут принимать участие в обсуждениях UX и конечных решениях, что у нас и происходит. Но фазы UX и разработки должны быть разделены.
Конечно, все зависит от контекста. Тут контекст — веб приложение. Для описания алгоритмов может и BDD подойдет нормально.
У нас большое количество автоматических тестов. Для них пишутся кейсы и они автоматизируются. Остальное exploratory тестирование в основном. Баланс примерно 4 разработчика на 1 тестировщика.
Если статья спорная — это же прекрасно, есть о чем поговорить.
Мы пробовали нанимать на работу людей через парное программирование. Попробовали на человеках 10 где-то. Отказались. Причина проста — довольно сложно сразу человеку въехать в проект и делать там что-то серьезное. Не у всех есть навыки парного программирования, а без опыта можно и растеряться особенно в незнакомой среде. Решать тривиальные задачи в паре чтобы проверить коммуникацию? Ну это не сильно эффективно.
У нас тоже два дня. Первый день разговор на 30 минут и тестовое задание на архитектуру на 2 часа — проверка на профпригодность.
Если все ОК, то второй день глубокое интервью на 2-2.5 часа по разным темам.
Ошибаемся мы очень редко. Может быть пропускаем хороших кандидатов, это да. Но из пары десятков человек, которых взяли, уволили только одного.
Я не HR к счастью :)
Опыт работы отлично описан
Специализация и профессиональные навыки — ну тут можно лучше структурировать наверное, хотя бы переносы строк между разделами вставить.
Можно еще добавить любимые книги по специальности, в моем круге вроде это легко делается. Пройденные курсы (если есть). Раз вы говорите «Постоянно повышаю свою квалификацию», то хотелось бы увидеть подтверждение.
www.targetprocess.com/product/
medium.com/the-content-factory/e8eb96d7a701
1 — детальный дизайн не лучше скетча во многих случаях, если уже есть дизайн всех готовых компонент. В этом случае, например, скетча более чем достаточно. И так ясно, где какая компонента будет. Думаю, таких случаев можно придумать еще
2 — Хорошее решение любой более-менее сложной проблемы невозможно придумать за 2 недели. Точка. Понятно, что форму логина можно придумать за час. Таймлайны в Targetprocess можно придумать за месяца 2 при достаточно интенсивной работе. 9 женщин не могут родить ребенка за месяц. С проектирование часто тоже так.
3 — Ничего не теряется. Надо просто правильно организовать процесс. И на выходе говно тоже зависит полностью от процесса и людей, которые в этом участвуют. Никаких принуждений не нужно. Нужно вовлекать в процесс всех на ранних стадиях и все будет хорошо.
2 — хорошее решение невозможно придумать за 2 недели. Если перед спринтом нет ничего, а только юзер стори, то для любой мало-мальски сложной проблемы не будет сделано хорошее решение. Посредственные — сколько угодно. Хорошие решения требуют времени. После 10 лет в продукте мы пришли к тому, что фазы UX и разработки разделены. UX фаза длинная и обычно нужно десяток итераций, чтобы найти хорошее решение.
3 — разбиение большой задачи на маленькие и решение каждой задачи в контексте спринта — плохая практика. Очень легко потом получить странный функционал, который нужно будет переделать. Гораздо эффективнее продумать важные кейсы заранее и придумать решение, которое будет элегантно решать большинство из них. Конечно, можно ошибиться с самими кейсами. Поэтому если знания в домене невелики, то лучше выпустить хоть что-то на рынок и собрать фидбек. Если знаний много — это не обязательно делать.
По поводу реализации и дизайна все зависит от обстоятельств. В идеальном мире у разработчиков есть все, что нужно перед началом работы. В реальном конечно же нет. Если есть возможность, надо приближаться к идеалу. Если нет, работать с имеющейся информацией. Мы тоже когда начинали v.3 не имели готового дизайна, а всего лишь общую идею с приличной глубиной проработки. Дизайн устаканивался несколько месяцев, и конечно вся команда работала над функционалом в это время. Просто потом было много переделок, но тут уж нужно решить, что важнее — деньги сэкономить или время.
Разработчики могут принимать участие в обсуждениях UX и конечных решениях, что у нас и происходит. Но фазы UX и разработки должны быть разделены.
У нас большое количество автоматических тестов. Для них пишутся кейсы и они автоматизируются. Остальное exploratory тестирование в основном. Баланс примерно 4 разработчика на 1 тестировщика.
Если статья спорная — это же прекрасно, есть о чем поговорить.
У нас тоже два дня. Первый день разговор на 30 минут и тестовое задание на архитектуру на 2 часа — проверка на профпригодность.
Если все ОК, то второй день глубокое интервью на 2-2.5 часа по разным темам.
Ошибаемся мы очень редко. Может быть пропускаем хороших кандидатов, это да. Но из пары десятков человек, которых взяли, уволили только одного.
Опыт работы отлично описан
Специализация и профессиональные навыки — ну тут можно лучше структурировать наверное, хотя бы переносы строк между разделами вставить.
Можно еще добавить любимые книги по специальности, в моем круге вроде это легко делается. Пройденные курсы (если есть). Раз вы говорите «Постоянно повышаю свою квалификацию», то хотелось бы увидеть подтверждение.