Экономия на строчках кода выливается в его усложнение.
И лучше 20 строк понятного и простого кода, чем отладка кода с какими-то подписками и событиями стороннего фреймворка.
Вообще Event модель подразумевает, что клинты подписываются, отписываются, ветвятся и складываются в цепочки. Для UI общая event модель в общем случае оверхед, для этого MS ввели во фреймворк InotifyPropertyChanged, который вполне себе решает эту задачу.
Да и в предложении обычно сложность не в том, что много кода, а в том, что надо понять что он делает, а главное каким образом адаптировать его под новые требования. Чем проще код, тем проще оценить время переделки.
В вашей статье не доказано, что стандартные средства не подходят и вы вынуждены использовать сторонний фреймворк, который кстати сказать хрен знает как и кем протестирован и какие у него есть подводные камни.
Мне не очень нравится подход Performance Review. Когда сотруднику руководитель поначитавшись книжек про 360 review и т.п. начинает давать обратную связь.
И потом когда говорит вот у тебя тут плохо и там плохо, сразу напрашивается вопрос, а хрен ли ты такой умный ждал 3 месяца!? Почему не сказал сразу. Мне последовал ответ, что ты должен был видеть сам, после чего я послал и руководителя и контору подальше.
Не очень нравится слово критика — слишком сильный и субъективный критерий, без альтернативы.
Критика в стиле: "ты делаешь вот это плохо" — полное дерьмо, в полной мере раскрывающая бездарность руководителя. От такой критики толку нет.
Если рассматривать рабочий поцесс общо. Со стороны работодателя есть набор вопросов, задач, зон ответственности и т.д., которые необходимо покрывать. В команде это может делать кто-то лучше, кто-то хуже. С работником Заранее!!! Надо определить его цели. В соответствии с этими целями и оценивать результат из серии вот тут справился, а вот тут не очень. Что можно сделать чтобы укрепить/развить нужный навык.
Performance Review не более, чем синхронизация заранее обговоренных ожиданий от работника с текущим состоянием, по мнению руководителя.
И при регулярном обсуждении работы ( не раз в год) синхронизация становится, только в радость. И да если ваш подчинённый не справляется, вина руководителя ни чуть не меньше, чем самого работника. Именно руководитель одобрял его прием на работу или соглашался работать с таким коллективом.
Странный подход менеджмента, работают по принципу индуса в саппорте на первой линии: решение проблемы осуществляется поиском в Knowledge Base нужной статьи, без понимания деталей. Для решения узкой проблемы, в разных продуктах у одной и той же фичи разный приоритет, вы берете и перестраиваете работу полностью. Вместо того, чтобы свести васю из продукта с мишей из сервера и сказать: парни надо сделать такую фичу, договоритесь о тех деталях и все.
Почему бы не сделать приоритет новой фичи одинаковым и координировать реализацию фичи сразу в трех продуктах?
Почему не выделить людей ответственных за Product Area во всех трех типах продуктов?
Странно держать многомиллионный бизнес на клауд платформе.
Даже если клауд провайдеры "мамой клянутся" что у них там все перезащищено, бэкап держать надо, да и при наличии it штата, возможно проще хостить все у себя. Всегда думал, что клиенты клауд провайдеров, это либо мелкие it компании ( на начальном этапе выгоднее заказать, чем пилить свое), либо компании бизнес которых, не особо завязан на it.
Очередь задач
Часто крупные задачи в проекте необходимо разделять на части. Многие из них скапливаются, образуя очередность. В этом случае менеджеру продукта необходимо тщательно поработать со всеми задачами бэклога, определив верные приоритеты для каждой.
Очередное присвоение аджайлом практики, которая была задолго до него. Этот подход называется — «декомпозиция», из системного анализа.
Итеративная разработка означает, что сама команда может решить, что она может сделать, исходя из своих возможностей и опыта предыдущей итерации.
Итеративность точно также присуствовала до аджала. Итеративный процесс позволяет приближаться к намеченной цели асимптотически. Почитайте историю изобретения Калашниковым М.Т. своего оружия.
Сотрудничество с клиентами является ключевым моментом в методологии Agile
Если бы вы работали в бизнесе, то любой продукт ориентирован на клиента и заказчика.
Value stream analysis
Это аналогия кривой «спроса и предложения» и бюджетирования. Каким образом при минимуме бюджета, можно удовлетворить максимум потребеностей.
Ох как же айтишники любят изобретать велосипеды. Учите историю индустриализации. Это называется оперативка. Почитайте и поспрашивайте как это было. Более того процесс производства на порядки сложнее чем процесс написания софта.
Боже упаси от таких менеджеров, которые вместо управленческих решений смотрят в графики и считают скорость в задачах.
Такое усложнение и сужение взгляда на управление просто верх некомпетентности.
Не мешайте людям работать, смотрите на рузультат. Разработка ПО сильно сложнее чем снятие пары тривиальных метрик.
Меня всегда удивляет, тот факт, что айтишники в основном с техническим образованием. Но при этом менеджеры сложную модель разработки пытаются уложить в 2-3 метрики и на их основе принимать решение, один скрам с велосити чего стоит.
Нерадивые менеджеры отсутствие навыков управления пытаются компенсировать наличием нерелевантных метрик.
А приведите сравнение с такими монстрами как Informatica со своим стеком для поставки сообщений.
Вообще счётчик кол ва переданных сообщений не более, чем популизм.
А что за платежная система? Можно поподробнее про характеристики? Сколько платежей в секунду можете процессить? Какие операторы, типы операторов.
Как я уже говорил, платеж — это довольно сложно.
такие высказывания не придают значимости.
Вы очень еще любите говорить про enterprise. Enterprise — это когда не только вы зависите от систем, но и сторонние системы зависят от вас. А платежная система это не более, чем продукт для небольшой IT компании.
Мой каммент относится к автору, не к переводчику.
Опять какой-то теоретический булшит про итеративную разработку без примеров, деталей и конкретики.
Принцип итеративной разработки можно применить к почти любой области, а не только к той, с которой взаимодействует пользователь.
Именно, Итеративной разработке уже 100500 лет, видимо современные программисты совсем далеки от пика индустриализации, производства и конструирования. То же семейство оружия Калашникова Михаила Тимофеевича (КМТ), вполне себе результат итеративного подхода.
В итеративной разработке существует 100500 разных стратегий и подходов. При разработке основная цель это реализовать целевую функцию! И судя по картинке автора, КМТ должен был начать с рогатки, но в реальности это не так. Целевая функция может быть реализована не оптимальна/ не полностью, но так или иначе первый шаг к решению проблемы уже будет сделан.
Как можно непрерывно интегрировать проект каждый день, если для его завершения требуются месяцы, а не дни?
Не верно выбрана целевая функция или стратегия реализации. На сегодня сложно найти задачу, которую пришлось бы решать заново. При реализации целевой функции как правило переиспользуют уже существующие технологии и компоненты, жертвуя простотой, скоростью, универсальностью, гибкостью и т.д. но только для того чтобы понять, что реализация целевой функции принесет выгоду.
Вместо того, чтобы спрашивать «как построить большой проект?», вы должны спросить: «как разделить большой проект таким образом, чтобы я мог построить самый маленький полезный кусок?»
Чем больше шкаф — тем громче падает. Изначально строить большой проект — утопия. Как пример история Линукса и гита. Линус решал свою узкую задачу, а получилось вон чего.
Идея итеративной разработки заключаетсяв поиске различных способов решения проблемы. Она нацелена на то, чтобы реализовать большой проект двигаясь небольшими шагами, а не нацеливаться сразу на конечную цель.
Автор несет бред, никто с нуля большого ничего не делает, это противоречит основному закону эволюции: новая форма получается и предыдущей устойчивой формы, доказавшей свою жизнеспособность, при этом не факт, что новая форма будет жизнеспособна.
Переводчику +, автору жирный минус, пересказывает теорию без опыта.
А вам стоит обратить внимание на то, что только с 4-го издания PMBoK (2008 год) в нём появляются элементы гибких методологий, хотя до этого там был ТОЛЬКО водопад.
Экономия на строчках кода выливается в его усложнение.
И лучше 20 строк понятного и простого кода, чем отладка кода с какими-то подписками и событиями стороннего фреймворка.
Вообще Event модель подразумевает, что клинты подписываются, отписываются, ветвятся и складываются в цепочки. Для UI общая event модель в общем случае оверхед, для этого MS ввели во фреймворк InotifyPropertyChanged, который вполне себе решает эту задачу.
Да и в предложении обычно сложность не в том, что много кода, а в том, что надо понять что он делает, а главное каким образом адаптировать его под новые требования. Чем проще код, тем проще оценить время переделки.
В вашей статье не доказано, что стандартные средства не подходят и вы вынуждены использовать сторонний фреймворк, который кстати сказать хрен знает как и кем протестирован и какие у него есть подводные камни.
Мне не очень нравится подход Performance Review. Когда сотруднику руководитель поначитавшись книжек про 360 review и т.п. начинает давать обратную связь.
И потом когда говорит вот у тебя тут плохо и там плохо, сразу напрашивается вопрос, а хрен ли ты такой умный ждал 3 месяца!? Почему не сказал сразу. Мне последовал ответ, что ты должен был видеть сам, после чего я послал и руководителя и контору подальше.
Не очень нравится слово критика — слишком сильный и субъективный критерий, без альтернативы.
Критика в стиле: "ты делаешь вот это плохо" — полное дерьмо, в полной мере раскрывающая бездарность руководителя. От такой критики толку нет.
Если рассматривать рабочий поцесс общо. Со стороны работодателя есть набор вопросов, задач, зон ответственности и т.д., которые необходимо покрывать. В команде это может делать кто-то лучше, кто-то хуже. С работником Заранее!!! Надо определить его цели. В соответствии с этими целями и оценивать результат из серии вот тут справился, а вот тут не очень. Что можно сделать чтобы укрепить/развить нужный навык.
Performance Review не более, чем синхронизация заранее обговоренных ожиданий от работника с текущим состоянием, по мнению руководителя.
И при регулярном обсуждении работы ( не раз в год) синхронизация становится, только в радость. И да если ваш подчинённый не справляется, вина руководителя ни чуть не меньше, чем самого работника. Именно руководитель одобрял его прием на работу или соглашался работать с таким коллективом.
Почему бы не сделать приоритет новой фичи одинаковым и координировать реализацию фичи сразу в трех продуктах?
Почему не выделить людей ответственных за Product Area во всех трех типах продуктов?
Я вел речь про IT на аутсорс можно отдавать все, что не является критичным, а там уж каждому решать
Опять таки при определенном размере IT компании дешевле держать инфраструктуру у себя, нежели постоянно кому-то платить.
Странно держать многомиллионный бизнес на клауд платформе.
Даже если клауд провайдеры "мамой клянутся" что у них там все перезащищено, бэкап держать надо, да и при наличии it штата, возможно проще хостить все у себя. Всегда думал, что клиенты клауд провайдеров, это либо мелкие it компании ( на начальном этапе выгоднее заказать, чем пилить свое), либо компании бизнес которых, не особо завязан на it.
Все что можно купить это расходы. Эмоции они создаются самостоятельно, если голова конечно позволяет ))
У людей есть дурацкая привычка думать за других и учить других, вместо того чтобы понять мотивы.
Платить за рекламу и фантик — удел хомячья.
При чем не виртуально, а вполне реально)
С телефона не позволяет редактировать, по этому дописал.
Так вот и я про что, у кого нет женщины, тот дрочит.
Виртуальный досуг за реальные деньги не для меня.
Итеративность точно также присуствовала до аджала. Итеративный процесс позволяет приближаться к намеченной цели асимптотически. Почитайте историю изобретения Калашниковым М.Т. своего оружия.
Если бы вы работали в бизнесе, то любой продукт ориентирован на клиента и заказчика.
Это аналогия кривой «спроса и предложения» и бюджетирования. Каким образом при минимуме бюджета, можно удовлетворить максимум потребеностей.
Agile — это гербалайф для айтишников.
Ох как же айтишники любят изобретать велосипеды. Учите историю индустриализации. Это называется оперативка. Почитайте и поспрашивайте как это было. Более того процесс производства на порядки сложнее чем процесс написания софта.
Боже упаси от таких менеджеров, которые вместо управленческих решений смотрят в графики и считают скорость в задачах.
Такое усложнение и сужение взгляда на управление просто верх некомпетентности.
Не мешайте людям работать, смотрите на рузультат. Разработка ПО сильно сложнее чем снятие пары тривиальных метрик.
Меня всегда удивляет, тот факт, что айтишники в основном с техническим образованием. Но при этом менеджеры сложную модель разработки пытаются уложить в 2-3 метрики и на их основе принимать решение, один скрам с велосити чего стоит.
Нерадивые менеджеры отсутствие навыков управления пытаются компенсировать наличием нерелевантных метрик.
Вообще счётчик кол ва переданных сообщений не более, чем популизм.
такие высказывания не придают значимости.
Вы очень еще любите говорить про enterprise. Enterprise — это когда не только вы зависите от систем, но и сторонние системы зависят от вас. А платежная система это не более, чем продукт для небольшой IT компании.
Опять какой-то теоретический булшит про итеративную разработку без примеров, деталей и конкретики.
Именно, Итеративной разработке уже 100500 лет, видимо современные программисты совсем далеки от пика индустриализации, производства и конструирования. То же семейство оружия Калашникова Михаила Тимофеевича (КМТ), вполне себе результат итеративного подхода.
В итеративной разработке существует 100500 разных стратегий и подходов. При разработке основная цель это реализовать целевую функцию! И судя по картинке автора, КМТ должен был начать с рогатки, но в реальности это не так. Целевая функция может быть реализована не оптимальна/ не полностью, но так или иначе первый шаг к решению проблемы уже будет сделан.
Не верно выбрана целевая функция или стратегия реализации. На сегодня сложно найти задачу, которую пришлось бы решать заново. При реализации целевой функции как правило переиспользуют уже существующие технологии и компоненты, жертвуя простотой, скоростью, универсальностью, гибкостью и т.д. но только для того чтобы понять, что реализация целевой функции принесет выгоду.
Чем больше шкаф — тем громче падает. Изначально строить большой проект — утопия. Как пример история Линукса и гита. Линус решал свою узкую задачу, а получилось вон чего.
Автор несет бред, никто с нуля большого ничего не делает, это противоречит основному закону эволюции: новая форма получается и предыдущей устойчивой формы, доказавшей свою жизнеспособность, при этом не факт, что новая форма будет жизнеспособна.
Переводчику +, автору жирный минус, пересказывает теорию без опыта.