Думаю, что для опытных менеджеров и Скрам-мастеров здесь не будет ничего нового, материал пригодится скорее начинающим Скрам-мастерам или разработчикам, работающим по Скраму.
Это всем пригодится. Надоело слышать от людей, что Скрам и Аджайл подходят везде и для всего, а PMI - это только для HelloWorld-ов.
Молоко в белой чашке, стоящей на столе, покрытом белой скатертью - это понятно, здесь нет противоречий. Да, технически (очень) сложно - но любой понимает, что должно получиться в результате. Более корректной аналогией было бы задание "нарисовать чёрное пятно белой краской".
Было, но, к сожалению, не настолько ярко. Сомневаюсь, что ещё на одну статью хватит - даже такую маленькую. Я видеоролик "Эксперт" потому и выбрал, что в тему, понятно и посмеяться есть над чем.
Ни разу не спорю насчёт требований к ТЗ, готов подписаться под каждой строчкой. Если сам готовлю - делаю так же (список чуть-чуть другой, но на 95% совпадает). Статья про то, что делать, когда задача "рисовать красное зелёным цветом" уже прилетела. Как её переформулировать, чтобы подсластить пилюлю тому, кто будет реализовывать.
Ценю предложенное решение за юмор и находчивость (и да, я его видел - тема всё-таки не новая), но Вы уже сами ответили на свой же комментарий. Не будет заказчик доволен, к сожалению. Формальное следование требованиям - легчайший, по моему опыту, способ получить судебные иски и испортить свою репутацию.
Ролик показывает проблему несколько гиперболизированно - согласен. В той постановке проблемы ролика, которую Вы обозначили, виноват больше всего менеджер, который не провалидировал требования (на противоречивость, тестируемость и т.п.). То, над чем смеются другие - неумение выражать свои желания клиентом. Я не хочу искать, кто из них "на самом деле" больше виноват. Обе точки зрения объединяет то, что в результате больше всех будет страдать ответственный за реализацию специалист. Моя статья - это просто небольшая подсказка для менеджеров, как можно превращать неудобные задачи (неважно по чьей вине возникшие) в такие, за которые которые будет приятно браться.
"Подгорает" здесь не в смысле "подо мной уже стул тлеет после чтения твоего кода", а в смысле "у нас сроки/проект горят". Т.е. вопрос всё равно о неких цифрах и фактах, а не о субъективном восприятии. Извиняюсь, если неточно выразился.
Вот именно для того, чтобы не спорить, что есть баг, а что есть говнокод (или кто из двух кодообезьян говнокодистее, или какой стиль именования/отступов/расстановки скобок самый правильный, или какой из /анти/паттернов является на самом деле таковым), я и предлагаю сводить всё к числам. Боль есть? - Значит говно! Работает и ни у кого не подгорает? - Молодцы, продолжайте!
Если до рефакторинга в куске кода находили 4 бага в неделю, а после стало в среднем 1.5, то до рефакторинга код был явно не очень.
Если одна сферическая задача в вакууме раньше занимала 36.2 часа разработки, а после переписывания стала закрываться за 7.1 часов - аналогично.
[совсем реальный кейс с настоящими цифрами] Если раньше один критичный алгоритм занимал 10.000 строк кода и покрывал 17 возможных комбинаций входных значений из 640.000, а потом стал занимать 100 строк (просто сотня, а не сто тысяч) и покрывать все 640.000...
Нет, официально они нигде не принимаются (хотя по факту кое-где могут закрыть глаза). По личному опыту это было так: заходим в ТЦ, спрашивают galimybių pasas, жена делает глаза кота из Шрека и показывает сертификат прививки Спутником. Большинство говорит "у нас такое конечно нельзя, но вы проходите". Но один раз нарвались на принципиальную тётеньку. Примерно 10 раз прокатило, 1 - нет.
P.S.: Это касается и анализов тоже. "Не европейское - значит, понарошку."
При въезде с прививкой "Спутником" сдаётся анализ на антитела за 30-35 евро, после чего получается обычный паспорт возможностей (QR-код для входа в магазины и ТРЦ, на местном galimybių pasas), действующий 2 месяца. (Жена проделала это полтора месяц а назад.)
Потому что WPF не лучше WinForms. Да, в некоторых местах он шагнул далеко вперёд: темплейты, стили, анимации, свойства и события прокачались, разметку теперь не нужно переписывать при изменении DPI или языка (ну ладно, хотя бы не так часто и геморройно). Но в некоторых вещах (RichTextBox и WebBrowser) он просто не юзабелен, только WindowsFormsHost и спасает... P.S.: ~10 лет опыт работы с WPF, ~5 лет WinForms.
По моему опыту - это лотерея. Если кода, ипользующего подкапотные костыли .NET и WinForms мало, то вполне возможно, что удастся реально обойтись заявленным в статье Application.SetDefaultFont. Шаг в сторону (не ту) - здравствуйте, две недели отладки. Мигрировал по версиям 2 своих pet-проекта и 2 крупные enterprise-системы. Ни разу не угадал с прогнозом сложности таких изменений - причём ошибался в обе стороны.
Абсолютно верно! Я не против принципов Agile, я против возведения их в абсолют. Собственно, про это и примеры (надеюсь, герои моих примеров икают сейчас).
Попробую отстоять точку зрения автора статьи, исходя из своего опыта. IMHO, Agile - это про гибкость огранизации в контексте проиходящих изменений, возможность реагировать на feeback и делать pivot-ы. Перечисленные вами принципы являются советами, помогающими этого достичь. Упомянутые автором разбиение работы на порции - наиболее простым и часто используемым способом увеличить гибкость, управляемость и предсказуемость. Но если просто свести весь Agile к четырём принципам, будет следующее (реальные случаи):
"Работающий софт важнее документации, be agile!" - произносит менеджер, отвественный за спецификацию к сложной технической системе. А когда он пишет-таки спецификацию перед самым релизом, выясняется, что там написано "как хотелось бы", а не "как есть" - а соответствующие переделки займут пару месяцев.
"Люди важнее процессов" - заявляет организация и внедряет Agile. Из 32 человек команды разработки продукта с 1.5 миллионами клиентов за два месяца увольняются 29, которым не понравился такая передовая методология.
Под соусом "заказчик важнее контракта" были пропихнуты изменения, на реализацию которых были брошены все ресурсы. После чего заказчик начал угрожать иском на круглую сумму из-за того, что не было сделано то, что было указано в контракте (вот же сюрприз!).
В grpc не полетело его несуществование на момент разработки описываемого проекта. Мы релизнулись в октябре 2014, а grpc был представлен в августе 2016.
Если вопрос будет про «что лучше использовать сейчас?», я отвечу «а что лично Вам удобнее?» Я, поизучав grpc, для своих маленьких проектов с клиент-серверным взаимодействием остановился на WCF. Что я буду использовать, когда мне дадут enterprise-проект, связанный с клиент-сервером? Буду посмотреть в конкретной ситуации. Может — grpc, может — wcf, а может и cgi, реализованный на ассемблере. Всё от конкретных требований.
Это всем пригодится. Надоело слышать от людей, что Скрам и Аджайл подходят везде и для всего, а PMI - это только для HelloWorld-ов.
Как говорят, "борьба снаряда и брони". Хожу на собеседования, провожу собеседования - видел всякое, больше ничему не удивляюсь.
Красивое. Понимаю. Читал и ловил "вьетнамские флешбэки", хоть уже больше 10 лет прошло с тех пор.
Молоко в белой чашке, стоящей на столе, покрытом белой скатертью - это понятно, здесь нет противоречий. Да, технически (очень) сложно - но любой понимает, что должно получиться в результате. Более корректной аналогией было бы задание "нарисовать чёрное пятно белой краской".
Было, но, к сожалению, не настолько ярко. Сомневаюсь, что ещё на одну статью хватит - даже такую маленькую. Я видеоролик "Эксперт" потому и выбрал, что в тему, понятно и посмеяться есть над чем.
Ни разу не спорю насчёт требований к ТЗ, готов подписаться под каждой строчкой. Если сам готовлю - делаю так же (список чуть-чуть другой, но на 95% совпадает). Статья про то, что делать, когда задача "рисовать красное зелёным цветом" уже прилетела. Как её переформулировать, чтобы подсластить пилюлю тому, кто будет реализовывать.
Ценю предложенное решение за юмор и находчивость (и да, я его видел - тема всё-таки не новая), но Вы уже сами ответили на свой же комментарий. Не будет заказчик доволен, к сожалению. Формальное следование требованиям - легчайший, по моему опыту, способ получить судебные иски и испортить свою репутацию.
Ролик показывает проблему
несколькогиперболизированно - согласен. В той постановке проблемы ролика, которую Вы обозначили, виноват больше всего менеджер, который не провалидировал требования (на противоречивость, тестируемость и т.п.). То, над чем смеются другие - неумение выражать свои желания клиентом. Я не хочу искать, кто из них "на самом деле" больше виноват. Обе точки зрения объединяет то, что в результате больше всех будет страдать ответственный за реализацию специалист. Моя статья - это просто небольшая подсказка для менеджеров, как можно превращать неудобные задачи (неважно по чьей вине возникшие) в такие, за которые которые будет приятно браться.Потому что ссылка на оригинал присутствует в описании обоих приведённых видеороликов.
"Подгорает" здесь не в смысле "подо мной уже стул тлеет после чтения твоего кода", а в смысле "у нас сроки/проект горят". Т.е. вопрос всё равно о неких цифрах и фактах, а не о субъективном восприятии. Извиняюсь, если неточно выразился.
Вот именно для того, чтобы не спорить, что есть баг, а что есть говнокод (или кто из двух кодообезьян говнокодистее, или какой стиль именования/отступов/расстановки скобок самый правильный, или какой из /анти/паттернов является на самом деле таковым), я и предлагаю сводить всё к числам.
Боль есть? - Значит говно!
Работает и ни у кого не подгорает? - Молодцы, продолжайте!
Если до рефакторинга в куске кода находили 4 бага в неделю, а после стало в среднем 1.5, то до рефакторинга код был явно не очень.
Если одна сферическая задача в вакууме раньше занимала 36.2 часа разработки, а после переписывания стала закрываться за 7.1 часов - аналогично.
[совсем реальный кейс с настоящими цифрами] Если раньше один критичный алгоритм занимал 10.000 строк кода и покрывал 17 возможных комбинаций входных значений из 640.000, а потом стал занимать 100 строк (просто сотня, а не сто тысяч) и покрывать все 640.000...
Нужно продолжать?
Немножко юмора из личного опыта (комментарии в реальном Enterpsise-коде):
// Массив вместо ArrayList использован здесь просто из-за лени.
// Something about dark magic. Do not delete this emty "if", because it causes view invalidation.
(Моё любимое, for ever, судя по истории - коммент на месте удалённой строки кода) // Юра, извини.
Нет, официально они нигде не принимаются (хотя по факту кое-где могут закрыть глаза). По личному опыту это было так: заходим в ТЦ, спрашивают galimybių pasas, жена делает глаза кота из Шрека и показывает сертификат прививки Спутником. Большинство говорит "у нас такое конечно нельзя, но вы проходите". Но один раз нарвались на принципиальную тётеньку. Примерно 10 раз прокатило, 1 - нет.
P.S.: Это касается и анализов тоже. "Не европейское - значит, понарошку."
При въезде с прививкой "Спутником" сдаётся анализ на антитела за 30-35 евро, после чего получается обычный паспорт возможностей (QR-код для входа в магазины и ТРЦ, на местном galimybių pasas), действующий 2 месяца. (Жена проделала это полтора месяц а назад.)
Потому что WPF не лучше WinForms. Да, в некоторых местах он шагнул далеко вперёд: темплейты, стили, анимации, свойства и события прокачались, разметку теперь не нужно переписывать при изменении DPI или языка (ну ладно, хотя бы не так часто и геморройно). Но в некоторых вещах (RichTextBox и WebBrowser) он просто не юзабелен, только WindowsFormsHost и спасает...
P.S.: ~10 лет опыт работы с WPF, ~5 лет WinForms.
По моему опыту - это лотерея. Если кода, ипользующего подкапотные костыли .NET и WinForms мало, то вполне возможно, что удастся реально обойтись заявленным в статье Application.SetDefaultFont. Шаг в сторону (не ту) - здравствуйте, две недели отладки. Мигрировал по версиям 2 своих pet-проекта и 2 крупные enterprise-системы. Ни разу не угадал с прогнозом сложности таких изменений - причём ошибался в обе стороны.
Абсолютно верно! Я не против принципов Agile, я против возведения их в абсолют. Собственно, про это и примеры (надеюсь, герои моих примеров икают сейчас).
Попробую отстоять точку зрения автора статьи, исходя из своего опыта. IMHO, Agile - это про гибкость огранизации в контексте проиходящих изменений, возможность реагировать на feeback и делать pivot-ы. Перечисленные вами принципы являются советами, помогающими этого достичь. Упомянутые автором разбиение работы на порции - наиболее простым и часто используемым способом увеличить гибкость, управляемость и предсказуемость. Но если просто свести весь Agile к четырём принципам, будет следующее (реальные случаи):
"Работающий софт важнее документации, be agile!" - произносит менеджер, отвественный за спецификацию к сложной технической системе. А когда он пишет-таки спецификацию перед самым релизом, выясняется, что там написано "как хотелось бы", а не "как есть" - а соответствующие переделки займут пару месяцев.
"Люди важнее процессов" - заявляет организация и внедряет Agile. Из 32 человек команды разработки продукта с 1.5 миллионами клиентов за два месяца увольняются 29, которым не понравился такая передовая методология.
Под соусом "заказчик важнее контракта" были пропихнуты изменения, на реализацию которых были брошены все ресурсы. После чего заказчик начал угрожать иском на круглую сумму из-за того, что не было сделано то, что было указано в контракте (вот же сюрприз!).
Если вопрос будет про «что лучше использовать сейчас?», я отвечу «а что лично Вам удобнее?» Я, поизучав grpc, для своих маленьких проектов с клиент-серверным взаимодействием остановился на WCF. Что я буду использовать, когда мне дадут enterprise-проект, связанный с клиент-сервером? Буду посмотреть в конкретной ситуации. Может — grpc, может — wcf, а может и cgi, реализованный на ассемблере. Всё от конкретных требований.