KR
Специально для автора отзыва "топовые задачи, как всегда, хотя решать поленился" передаем эту песню, то есть, ссылку на разбор https://m.habr.com/company/gridgain/blog/428369/
Size: a a a
2018 November 02
GK
Специально для автора отзыва "топовые задачи, как всегда, хотя решать поленился" передаем эту песню, то есть, ссылку на разбор https://m.habr.com/company/gridgain/blog/428369/
Ну, две задачи простые, а в одной опять формулировка мутная. (Разбор ещё не смотрел)
AP
Обратная связь в этом году очень порадовала. Всем, кто не поленился оставить пару слов про активности кроме докладов, огромное спасибо от условно трепетного маркетолога.
А есть какой-то шанс увидеть какие-то обощенные результаты?
KR
А есть какой-то шанс увидеть какие-то обощенные результаты?
Кто каким путем пошел в решении?
AP
Кто каким путем пошел в решении?
Мне больше интересны оценки на доклады
KR
Это к оргам тогда. У каждого спонсора только про себя.
PD
Послушал тут последний доклад Бугаенко и подумал. По сути он пропагандирует распространение идеи 'fail fast' на процесс разработки. Это приведет к увеличению качества кода, но не качества продукта.
А как бы расширить этот подход на процессы ДО написания кода. Анализ, UX, постановку и т.п.
В рамках классической картинки про 'чем раньше найти ошибку, тем дешевле править'.
А как бы расширить этот подход на процессы ДО написания кода. Анализ, UX, постановку и т.п.
В рамках классической картинки про 'чем раньше найти ошибку, тем дешевле править'.
IK
Scrum процессы же. И xp
IK
Он скорее про то говорил, что ваш пацплайн должен быть жёстким и процесс ревью кода максимально автоматическим
J🎩
Scrum процессы же. И xp
не, это надо на процессы продакта и ux смотреть. До скама и ХП
IK
Так продакт и ux как раз в тех же процессах. У нас во всяком случае
IK
Максимально просто и быстро сделать, собрать аналитику по тому как пользуются и фидбек, и думать что дальше
IK
И с точки зрения того что и с точки зрения того как
PD
Нее, это все не про fail first. Вот когда проекты не доходят до анализа, постановки не доходят до UX, UX не доходит до разработки - это интересно.
PD
Если постановка с плохой идеей попала в бэклог - это как критикал обнаружили на проде.
PD
А максимально жёсткий пайплайн - это очевидное следствие из 'чем раньше фигню заметил, тем дешевле исправить', тут в докладе ничего нового.
PD
Но качество кода без качества продукта смысла не имеет (
PD
Но вообще Егор умный, так что главное содержание доклада - это его название. А 45 минут слайдов были иллюстрацией 'как делать нельзя' )
2018 November 03
IK
Это вопрос к тому как у вас процессы построены. У нас продукт приходит с проблемой юзеров и возможно инфой что можно сделать. Мы все вместе думаем надо ли делать, что и как. Как проверить что продукт прав максимально быстро и просто
IK
Как ещё быстрее фейлить я не представляю и зачем. Первое когда фейлится это сбор статистики и инфы от/по клиентам