Да, вы правы, это скорее было похоже на Канбан, потому как не было спринтов с ограничением по времени. Но и визуализации тоже особой не было, просто список задач в Excel. Единственное, что вспомнилась ещё одна ассоциация, что если задача не решалась в течение 2-х недель, то приходилось с ней что-то делать. То ли дробить на более мелкие, то ли как-то перестраивать общую картину.
Очень хороший текст, спасибо автору! Мне ближе Scrum, он как-то хорошо ложится на проект. Но идея комбинирования двух подходов тоже интересная. Мы однажды практиковали что-то подобное скраму в проекте, тогда еще не было такого названия. Просто составляли список задач, которые выдавали пользователи, затем оценивали их сложность по времени предполагаемой реализации. После чего выбирали задачи для реализации. Обычно брали для начала что-то среднее по сложности для разогрева. Слишком тяжелые могли провалить, а слишком легкие ничему не учили и не разогревали. Из своих ощущений помню 3: 1) Такой анализ помогал выстраивать последовательность выполнения, видишь общую картину и какие-то связи между задачами; 2) мелкие задачи выполняли время от времени, причем даже не по причине логики, а просто для настроения между более сложными задачами. Причем сами программисты предложили их группировать и выполнять типа небольшими пачками; 3) программисты наглядно увидели, что работа руководителя проекта - это не пустое времяпровождение, а реальная работа, где надо собрать информацию, сгруппировать и проанализировать ее, а затем принимать решения, причем зачастую не имея полной информации, т.е., приходилось брать ответственность на себя и принимать груз возможной ответственности за ошибки. Потому как это делалось не где-то в отдельном кабинете, а вместе с ними. Т.е., они получали хороший менеджерский опыт. Ну и наградой конечно был момент, когда приходили к пользователям и строго по списку показывали, что сделано. И они, и мы получали кучу позитивной энергии. P.S. Там по ходу есть одна неточность в таблице, п.9, Поток работы, перепутаны столбцы.
Хороший текст, спасибо автору. А как же VC.ru, вы его не упомянули. Неплохой ресурс, хотя конечно все в одном месте, но тем не менее довольно часто бывают интересные материалы.
Да, атмосфера там в последнее время стала реально токсичная. Набрали каких-то первокурсников и те косят все подряд без разбору. Именно это больше всего и отталкивает от посещения этого ресурса в последнее время.
Я до сих пор не до конца понимаю что это значит. Ожидал разъяснения какого-то разъяснения, но оказалось, что формат статьи не такой... Может хотя бы кто-то из комментаторов объяснит?
Что такое "возвращаемое значение"? Если кратко, то это значение, которое возвращает функция.
Особенность возвращаемого значения состоит в том, что его можно присвоить в другую переменную.
Некоторые функции возвращают значение, некоторые не возвращают.
Признаком того, что функция возвращает значение является указание на это после круглых скобок с параметрами функции.
Пример, как это выглядит в Swift:
func sum (a: Int, b: Int) -> Int {
var с = a + b
return c
}
В этом примере мы объявляем функцию с названием sum.
В круглых скобках - параметры функции, где указаны входные параметры. Т.е., мы получаем значения, которые будут использоваться в расчетах.
После круглых скобок идет стрелка и указание типа: -> Int.Это и есть обозначение того, что данная функция возвращает значение. Если такой стрелки нет, то функция значения не возвращает.
Также внутри, в фигурных скобках в теле функции дополнительно используется слово return, которое тоже показывает, что данная функция возвращает значение.
Как происходит возврат значения? - Мы объявляем новую переменную и присваиваем ей значение из функции, как результат некой операции, которую функцию выполнила.
var d = sum(a: 5, b: 3)
В итоге, переменная d теперь хранит значение 8, которое ей вернула функция sum.
Если же, в объявлении данной функции не указано -> Int, то она ничего не возвращает и, соответственно, ничего присвоить в другую переменную мы не можем.
Несколько раз пробовал пользоваться этим ресурсом, но так и не смог привыкнуть к их дизайну. Как-то он так сделан, что в глазах рябит, масса мелких деталей и в результате трудно читать.
Это еще что, я как-то подрабатывал помощником преподавателя, так ко мне на консультацию пришел однажды чел, взрослый, лет 35, который не понимал, что такое переменная и как она работает.
А моя личная боль на первых порах была в том, что никак не мог въехать в "возвращаемое значение". Хорошо помню как это раздражало в очередном тьюториале - "кто возвращает", "куда" и главное "зачем". Сейчас конечно смешно, но тогда это выглядело не то, что "магия", а какой-то мировой заговор преподавателей, которые твердят одно и то же, но не хотят объяснить толком что это такое.
Такой вопрос: например, есть компьютерная игра. С чего начать, чтобы защитить ее? Скажем так, дизайн у неё простой, там если что и надо защищать, так совсем немного. Основное код, а ещё точнее алгоритм игры. Хотелось бы защитить её в максимальном количестве стран, чтобы избежать неконтролируемого копирования. Что из озвученного вами в этом посте следует сделать в этом случае?
Я бы не сказал, что "бизнес-процесс" невнятный и расплывчатый термин. Он очень даже активно используется. Тот же Google выдаёт несколько тысяч результатов по нему.
А ChatGPT показал следующее соотношение между этими двумя терминами:
Бизнес-процесс состоит из множества операций, объединенных общей целью.
Операция — это более мелкая "единица работы", которая выполняется в рамках бизнес-процесса.
Читать и переводить своими руками можно только те тексты, которые или очень интересны, или нужны, например по работе. Тогда есть сильная мотивация и запоминается лучше. Не на все 100% конечно, но заметно лучше и главное получаешь положительную энергию.
Очень полезная тема! И видно, что автор действительно активно интересуется человеческим поведением, столько психологических концепций здесь использовано.
В набор критериев UX, после времени, я бы еще добавил дружелюбие и интересность. Не берусь судить как специалист в этой области, это просто из личных впечатлений. Например, пару раз бывало такое, что читаешь land страницу и она так хорошо написана, что в конце просто реально хочется что-то сделать. Купить что-нибудь, оформить подписку, написать отзыв и т.д. Т.е., прямо чувствуешь выброс ментальной энергии. Попытался как-то сформулировать, чем же приглянулась эта страница, и вот на уровне ощущений - это что-то такое, что написано в какой-то дружелюбной манере и что-то само по себе интересное.
А насчет времени, бывает читаешь читаешь текст о том, какую хорошую штуку продает сайт или приложение, но так до конца и не понимаешь, а что же это за штука такая? Что она реально делает. Т.е., в погоне за рекламой люди забывают нормально написать, что именно они продают.
И еще, если позволите, один пример. Он немного юморной, но все-таки в нем есть какая-то психологическая подоплека. Причем, это случалось не только со мной, но и с другими людьми. А именно, заходишь первый раз на сайт какого-нибудь почтовика, например, Gmail, Yandex и др., рассматриваешь как там все устроено и потом какое-то время не можешь найти кнопку, чтобы написать письмо. При этом понимаешь, что она здесь есть и должна быть на видном месте и каким-то образом выделена. Потом, конечно, находишь, она действительно большая и заметная, но вот в первые секунды получается какая-то слепая зона.
Единственное, что хотелось бы предложить автору скорректировать в этой теме, так это использование слова "манипуляции". И хотя они называются "доброжелательными", все-таки какой-то осадок остается. На мой взгляд здесь можно говорить о построении коммуникаций между участниками процесса, тем же продавцом и покупателем.
Да, вы правы, это скорее было похоже на Канбан, потому как не было спринтов с ограничением по времени. Но и визуализации тоже особой не было, просто список задач в Excel. Единственное, что вспомнилась ещё одна ассоциация, что если задача не решалась в течение 2-х недель, то приходилось с ней что-то делать. То ли дробить на более мелкие, то ли как-то перестраивать общую картину.
Очень хороший текст, спасибо автору! Мне ближе Scrum, он как-то хорошо ложится на проект. Но идея комбинирования двух подходов тоже интересная. Мы однажды практиковали что-то подобное скраму в проекте, тогда еще не было такого названия. Просто составляли список задач, которые выдавали пользователи, затем оценивали их сложность по времени предполагаемой реализации. После чего выбирали задачи для реализации. Обычно брали для начала что-то среднее по сложности для разогрева. Слишком тяжелые могли провалить, а слишком легкие ничему не учили и не разогревали. Из своих ощущений помню 3: 1) Такой анализ помогал выстраивать последовательность выполнения, видишь общую картину и какие-то связи между задачами; 2) мелкие задачи выполняли время от времени, причем даже не по причине логики, а просто для настроения между более сложными задачами. Причем сами программисты предложили их группировать и выполнять типа небольшими пачками; 3) программисты наглядно увидели, что работа руководителя проекта - это не пустое времяпровождение, а реальная работа, где надо собрать информацию, сгруппировать и проанализировать ее, а затем принимать решения, причем зачастую не имея полной информации, т.е., приходилось брать ответственность на себя и принимать груз возможной ответственности за ошибки. Потому как это делалось не где-то в отдельном кабинете, а вместе с ними. Т.е., они получали хороший менеджерский опыт. Ну и наградой конечно был момент, когда приходили к пользователям и строго по списку показывали, что сделано. И они, и мы получали кучу позитивной энергии. P.S. Там по ходу есть одна неточность в таблице, п.9, Поток работы, перепутаны столбцы.
И по поводу опроса, что такое «коллективные блоги на Английском»?
Хороший текст, спасибо автору. А как же VC.ru, вы его не упомянули. Неплохой ресурс, хотя конечно все в одном месте, но тем не менее довольно часто бывают интересные материалы.
Да, атмосфера там в последнее время стала реально токсичная. Набрали каких-то первокурсников и те косят все подряд без разбору. Именно это больше всего и отталкивает от посещения этого ресурса в последнее время.
Спасибо, отличный пример!
Отличный текст! Спасибо автору! Согласен полностью по поводу инженерного мышления.
Что такое "возвращаемое значение"? Если кратко, то это значение, которое возвращает функция.
Особенность возвращаемого значения состоит в том, что его можно присвоить в другую переменную.
Некоторые функции возвращают значение, некоторые не возвращают.
Признаком того, что функция возвращает значение является указание на это после круглых скобок с параметрами функции.
Пример, как это выглядит в Swift:
В этом примере мы объявляем функцию с названием sum.
В круглых скобках - параметры функции, где указаны входные параметры. Т.е., мы получаем значения, которые будут использоваться в расчетах.
После круглых скобок идет стрелка и указание типа: -> Int. Это и есть обозначение того, что данная функция возвращает значение. Если такой стрелки нет, то функция значения не возвращает.
Также внутри, в фигурных скобках в теле функции дополнительно используется слово return, которое тоже показывает, что данная функция возвращает значение.
Как происходит возврат значения? - Мы объявляем новую переменную и присваиваем ей значение из функции, как результат некой операции, которую функцию выполнила.
var d = sum(a: 5, b: 3)
В итоге, переменная d теперь хранит значение 8, которое ей вернула функция sum.
Если же, в объявлении данной функции не указано -> Int, то она ничего не возвращает и, соответственно, ничего присвоить в другую переменную мы не можем.
Здесь мы с вами, что называется "not the same")). Мне как раз более интересна именно архитектура of software.
не отказался бы от такой програмулины на телефоне. А то вот тоже бот обыгрывает, потому что зеваю.
Несколько раз пробовал пользоваться этим ресурсом, но так и не смог привыкнуть к их дизайну. Как-то он так сделан, что в глазах рябит, масса мелких деталей и в результате трудно читать.
Это еще что, я как-то подрабатывал помощником преподавателя, так ко мне на консультацию пришел однажды чел, взрослый, лет 35, который не понимал, что такое переменная и как она работает.
А моя личная боль на первых порах была в том, что никак не мог въехать в "возвращаемое значение". Хорошо помню как это раздражало в очередном тьюториале - "кто возвращает", "куда" и главное "зачем". Сейчас конечно смешно, но тогда это выглядело не то, что "магия", а какой-то мировой заговор преподавателей, которые твердят одно и то же, но не хотят объяснить толком что это такое.
Хорошая статья, спасибо автору!
Но а как же Viper, MVVM, MVP?
И более общий вопрос - что такое архитектура приложения?
Такой вопрос: например, есть компьютерная игра. С чего начать, чтобы защитить ее? Скажем так, дизайн у неё простой, там если что и надо защищать, так совсем немного. Основное код, а ещё точнее алгоритм игры. Хотелось бы защитить её в максимальном количестве стран, чтобы избежать неконтролируемого копирования. Что из озвученного вами в этом посте следует сделать в этом случае?
Вопрос конечно интересный))
Я бы не сказал, что "бизнес-процесс" невнятный и расплывчатый термин. Он очень даже активно используется. Тот же Google выдаёт несколько тысяч результатов по нему.
А ChatGPT показал следующее соотношение между этими двумя терминами:
Бизнес-процесс состоит из множества операций, объединенных общей целью.
Операция — это более мелкая "единица работы", которая выполняется в рамках бизнес-процесса.
Это выглядит достаточно логично.
Читать и переводить своими руками можно только те тексты, которые или очень интересны, или нужны, например по работе. Тогда есть сильная мотивация и запоминается лучше. Не на все 100% конечно, но заметно лучше и главное получаешь положительную энергию.
Очень полезная тема! И видно, что автор действительно активно интересуется человеческим поведением, столько психологических концепций здесь использовано.
В набор критериев UX, после времени, я бы еще добавил дружелюбие и интересность. Не берусь судить как специалист в этой области, это просто из личных впечатлений. Например, пару раз бывало такое, что читаешь land страницу и она так хорошо написана, что в конце просто реально хочется что-то сделать. Купить что-нибудь, оформить подписку, написать отзыв и т.д. Т.е., прямо чувствуешь выброс ментальной энергии. Попытался как-то сформулировать, чем же приглянулась эта страница, и вот на уровне ощущений - это что-то такое, что написано в какой-то дружелюбной манере и что-то само по себе интересное.
А насчет времени, бывает читаешь читаешь текст о том, какую хорошую штуку продает сайт или приложение, но так до конца и не понимаешь, а что же это за штука такая? Что она реально делает. Т.е., в погоне за рекламой люди забывают нормально написать, что именно они продают.
И еще, если позволите, один пример. Он немного юморной, но все-таки в нем есть какая-то психологическая подоплека. Причем, это случалось не только со мной, но и с другими людьми. А именно, заходишь первый раз на сайт какого-нибудь почтовика, например, Gmail, Yandex и др., рассматриваешь как там все устроено и потом какое-то время не можешь найти кнопку, чтобы написать письмо. При этом понимаешь, что она здесь есть и должна быть на видном месте и каким-то образом выделена. Потом, конечно, находишь, она действительно большая и заметная, но вот в первые секунды получается какая-то слепая зона.
Единственное, что хотелось бы предложить автору скорректировать в этой теме, так это использование слова "манипуляции". И хотя они называются "доброжелательными", все-таки какой-то осадок остается. На мой взгляд здесь можно говорить о построении коммуникаций между участниками процесса, тем же продавцом и покупателем.
Было бы здорово! Давно хочу такое. Даже удивляет, почему до сих пор оно не сделано.