Приветствую, Хаброзритель. В данной статье я хочу познакомить тебя с органайзером Notion, поделиться своим опытом использования. Также я дам несколько советов, идей, к которым я пришел со временем, учась планировать и использовать свое время, силы и мыслетоплево.
Некоторые мысли, конечно, не будут напрямую связаны с данной программой и не все советы я как-то выделил отдельно, не упусти их.
Надеюсь, что буду полезен и прошу под кат.
В этой статье попробуем разобраться нужно ли инженеру продуктовое мышление (и в каких случаях), какие плюсы (и минусы) это даёт, и возможно ли совместить в одном человеке два разных (часто противоречащих) образа мышления. Ведь разные образы мышления ведут в разным приоритетам, а как следствие и разным действиям.
Статей о TDD достаточно много, и я обратил внимание на то, что все они затрагивают преимущественно техническую составляющую этого подхода, и практически никак не описывают ментальные принципы, лежащие в основе TDD.
Поэтому я не хотел писать еще одну статью с описанием техники Red-Green-Refactor. Мне хотелось взглянуть на TDD немного глубже и описать, как и почему TDD влияет на поведение человека.
Вчера появился мем на просторах интернета, конечно, он забавный, однако, не имеет отношения к реальности. Да и забавен ровно настолько, насколько процветает ваше непонимание того, что в этих двух колонках.
Не пытаясь выступить адвокатам чего бы то ни было, хотел бы разъяснить определённые неточности мема, потому что, возможно, больше никто этого не сделает, но все примут за чистую монету.
Думаю, мало кто стал бы спорить, что передовые проекты индустрии разработки программного обеспечения, IT отделы корпораций, в своей работе используют инкрементально-итерационные подходы. Со временем, Agile оброс горой идеализма и шарлатанства: коучи, менторы, мотиваторы — случайные люди, рассказывают о том, как нужно поверить в схемки и диаграмки, чтобы проникнутся общей целью.
Цель данной статьи — поставить идеалистичное отношение к Agile с ног на голову — материалистически объяснить, когда Agile работает, как именно работают те или иные ценности и принципы; какой Agile идеалистический, а какой материалистический.
Привет! Представляю вашему вниманию перевод статьи «User stories are not requirements» автора Пер Лундхольм (Per Lundholm).
Слоны – не жирафы, а пользовательские истории – это не требования. Они имеют и общие черты и общий контекст, однако это не ставит между ними знак равенства. Тем не менее, многие полагают, что пользовательские истории являются своего рода новым прочтением того, что традиционно называется требованиями к программному обеспечению — ведь, должны же быть требования на проекте, правильно? Так вот, я отвечу — нет, и еще раз нет. Во – первых, это не требования, во – вторых, требования — это не то, что нам на самом деле нужно. Пользовательские истории — это прежде всего шанс увидеть различные варианты реализации, чтобы потом можно было воспользоваться открывшимися возможностями. А требования… это решить все наперед, чтобы потом в этом увязнуть.
Сегодня существует 100500 курсов по Data Science и давно известно, что больше всего денег в Data Science можно заработать именно курсами по Data Science (зачем копать, когда можно продавать лопаты?). Основной минус этих курсов в том, что они не имеют ничего общего с реальной работой: никто не даст вам чистые, обработанные данные в нужном формате. И когда вы выходите с курсов и начинаете решать настоящую задачу — всплывает много нюансов.
Поэтому мы начинаем серию заметок «Что может пойти не так с Data Science», основанных на реальных событиях случившихся со мной, моими товарищами и коллегами. Будем разбирать на реальных примерах типичные задачи по Data Science: как это на самом деле происходит. Начнем сегодня с задачи сбора данных.
И первое обо что спотыкаются люди, начав работать с реальными данными — это собственно сбор этих самых релевантных нам данных. Ключевой посыл этой статьи:
Мы систематически недооцениваем время, ресурсы и усилия на сбор, очистку и подготовку данных.
А главное, обсудим, что делать, чтобы этого не допустить.
По разным оценкам, очистка, трансформация, data processing, feature engineering и тд занимают 80-90% времени, а анализ 10-20%, в то время как практически весь учебный материал фокусируется исключительно на анализе.
Давайте разберем как типичный пример простую аналитическую задачу в трех вариантах и увидим, какими бывают «отягчающие обстоятельства».
И для примера опять же, мы рассмотрим подобные вариации задачи сбора данных и сравнения сообществ для:
Я пользовался методом управления проектами Scrum (скрам) с самого начала карьеры. Я изучал скрам в колледже. Тогда он считался лучшим методом управления разработкой программного обеспечения. Когда я начал работать, мне нравилось всё, что имеет отношение к скраму: ежедневные встречи, планирование, ретроспективные совещания, спринты и так далее. В конце концов, я пользовался на практике тем, чему меня учили.
Но через несколько лет я начал кое-что замечать: в последние дни спринта все бросаются доделывать всё то, чем занимались в предыдущие две недели, стремясь избежать переноса задач на будущее. Часто те, кто так поступали, брали на себя ненужный риск.
Почему? Разве какие-то задачи не могут подождать до следующей недели? Так ли важно доделать абсолютно всё до выходных? Нет, не так уж это и важно. А всё это происходит из-за того, что «Переносы задач — это плохо».
Читать полностью »
Привет! Меня зовут Артём и я тимлид в Skyeng. У моей команды разработки есть заказчик, он же продуктовый менеджер, он же просто Ваня. Ваня считает, что наша схема с оценкой задач не идеальна. Например, оценка в 2 дня ничего ему не даёт. Свою задачу на проде он увидит через неделю или дней 10. Или больше. Или меньше.
Читать полностью »
В течение всей истории разработки ПО, мы искали надежные способы оценки времени на реализацию задач и проектов. Но и спустя более чем 60 лет существования отрасли, наши прогнозы все еще оставляют желать лучшего. Может быть, дело не в том, как именно мы пытаемся оценивать, а в том, что мы вообще опираемся на оценки?
К примеру, возьмите методологию Scrum, по которой сегодня работают многие компании. Центральная идея Scrum — брать в спринт не больше задач, чем ваша команда способна за это время выполнить. На первый взгляд, звучит разумно. К сожалению, слишком часто на практике этот подход приводит к замедлению работы команды в обмен на иллюзию планирования. Позвольте объяснить, почему.
Читать полностью »
