Рубрика «agile»

В этом посте я расскажу о тех проблемах с которыми в течении года сталкивалась наша Scrum Front End команда при работе над приличным проектом. Мы начинали разрабатывать проект с нуля используя стек технологий React + Typescript. Оглядываясь назад я вижу многие миллионы выброшенные впустую просто из-за того, что процесс разработки не был поставлен с самого начала правильно. Но на это есть свои причины.
Читать полностью »

image

Изначально Agile ассоциировался исключительно с ИТ-сферой и стартапами. Для ИТ продуктов идеально подходит гибкая методология разработки и она легко ложиться в основу молодых проектов, которые только выходят на рынок.

А что делать большим традиционным компаниям, которые годами жили в WATERFALL проектах и чтобы согласовать новую кнопку на сайте проходят семь кругов бюрократического ада?

Сейчас мы наблюдаем распространение Agile в новых сферах: банковские структуры (и речь далеко не только о финтехах), транспортные услуги и пр.
Часть компаний применяют новую методологию к отдельным продуктам, некоторые, переводят целые подразделения в такой формат.
Читать полностью »

image

В 2001 году группа технологов и программистов, разделявших небанальные теории о том, как следует управлять разработкой ПО, встретились на горнолыжном курорте Сноубёрд, чтобы письменно изложить некоторые из этих концепций. Так родился «манифест Agile» — обманчиво простой документ, призванный пересмотреть догмы разработки ПО. Разработка ПО в стиле Agile превратилась в новый стандарт организации труда программистов в организации. Такие компании как Facebook, Amazon, Apple, Google и Netflix выстроили свои внутренние процессы разработки в соответствии с базовыми положениями этого манифеста. Учитывая абсолютные масштабы Agile и его общественный резонанс среди сторонников, легко убедиться, что Agile — самая влиятельная из всех когда-либо формализованных трактовок разработки ПО. Однако, Agile — это идеология. Нормативная система ценностей и убеждений, практически до основания впитавшихся в дело разработки ПО. Таким образом, софтверная индустрия сегодня дает интересную возможность оценить, как номинальные цели некоторой идеологии согласуются с ее воплощением на практике.
Читать полностью »

Девушка в IT, или 5 советов для амбициозных - 1В этом посте я специально не буду говорить отдельно о «рецепте для женщин», т.к. считаю, что схема успеха одна и та же, независимо от пола. Об отличиях и специфике «женского пути» будет в конце. Если кто-то интересуется только этой частью, смело скрольте до последнего раздела.

В конце прошлого года меня пригласили выступить на мероприятии Worldwide Conversation on Women’s Higher Education and Equality in the Workplace на факультете компьютерных наук ВШЭ. Это беседа о том, как в современном мире женщина может построить успешную карьеру в области науки, образования или информационных технологий, с какими сложностями она при этом сталкивается и как может их преодолеть.

Я была спикером «со стороны IT» и рассказывала, как мне кажется, вполне очевидные и сами собой разумеющиеся вещи. Но, делясь впечатлениями о мероприятии с друзьями и коллегами, обнаружила, что тема очень многим интересна и относятся к ней очень по-разному. Именно после этого и родилась статья. В ней я расскажу о моем опыте развития карьеры в IT-компании и том, что считаю важным делать, а чего, наоборот, избегать, чтобы стать успешным в своем деле.
Читать полностью »

Вводная часть


В предыдущем посте я писал как организовать процесс “грумминга” задач в системе JIra так чтобы “Менеджеру продукта” было удобно осуществлять навигацию по всему Беклогу продукта. Продолжая продуктовую тему напишу о том как я долго шел к пониманию того — что такое типы задач в Jira.

Важно тут сказать что дальше структуру которую я буду предлагать подойдет именно для процесса развития продукта(ов), но врятли будет корректной для управления проектами. Кстати если Вас волнует вопрос почему Agile это в большей степени фреймворк для управления продуктами но почитайте об этом вот тут.

Структура задач


В системе Jira на уровне проекта есть три уровня задач, это: Epics, Stories/Tasks, Sub-task. Оригинал статьи тут. Jira позволяет достаточно сильно кастомизировать эти сущности — можно менять названия, картинки, настраивать под эти задачи свои workflow. В этом то и кроется корень зла! Чем больше ты “кастомизируешь” систему под свои потребности не имею согласованного понимания что есть что, тем больше это вызывает вопросов и в конечном счете отторжение от работы в данном приложении.
Читать полностью »

Обратите внимание, что в названии нет знака вопроса. Я не хочу рассуждать, нужны менеджеры проектов в современной разработке программного обеспечения или нет. Практика показывает, что нет. Я только пытаюсь разобраться, почему так сложилось.

Работая более 20 лет в IT-индустрии, каждую новую разработку я начинал строить с проектного офиса. Более того, несколько раз мне приходилось объяснять руководству, зачем нанимать пиэмов. При наличии руководителей отделов, не так просто объяснить людям, которые не принимают непосредственного участия в разработке софта, что же именно будут делать менеджеры проектов. Приходилось преодолевать заметное сопротивление.

Но для меня было аксиомой, что проектный офис и менеджеры проектов являются основой успеха. И скажи мне кто-нибудь лет пять назад, что менеджеры проектов не нужны, я бы спорил с ним до конца.

Читать полностью »

Сказ про успех или Как мы уволили всех разработчиков или Король прогибания - 1

Доброго времени обращения земли вокруг оси суток, уважаемые хабрапацаны и хабранессы дамы и господа.

Недавно мне все надоело, задолбало захотелось сменить стезю профессиональной деятельности и занять новую для себя ипостать, чтобы в дальнейшем развиваться. Поэтому я подумал и решил стать бэтменом Agile-коучем минуя даже деятельность Scrum-мастера. Поэтому сегодня в данном посте мы поговорим про Agile или методику того, как работать чтобы все работало и ваша команда была эффективной и успешной и не хотела пахать от восьми и до обеда была мотивирована и сверкала жопой горящими глазами.

Но я пошел дальше и решил сделать свой Agile с пасьянсом паук и особями женского пола низкой социальной ответственности, покером и куртизанками, дураком и дурами, очком и путанами преимуществами и улучшениями.

Дисклеймер: данным постом я выражаю лишь свое субъективное мнение и не претендую на истину в последней инстанции. Также я не хочу никого обидеть, задеть, оскорбить, научить, заставить делать как я или показаться умнее и красноречивее, чем я есть. Я понимаю что данная методология может показаться кому-то не такой, какой она должна им показаться. Поэтому все сказанное ниже только мое мнение и больше ничье. Пожалуйста, не ругайтесь на меня в комментариях.

TL;DR Agile супер, работайте по Agile, делайте зарядку, будьте счастливы.

Если я вас заинтересовал, добро пожаловать под кат. Начнем. Поехали. Ай-да!
Читать полностью »

Как мы разбили разработку на команды (и забыли про бесконечные спринты и бесполезные стендапы) - 1

Я — PM в сервисе рассылок UniSender. 6 лет назад я пришёл программистом, а теперь отвечаю за взаимодействие между командами продукта. Раньше наша разработка состояла из одной распределённой команды и у нас было 2 беды. Но не дураки и дороги, а задержки по спринтам и скучные стендапы на полчаса.

Расскажу, как мы их решили.
Читать полностью »

Жил на свете такой человек – Стивен Кови. Однажды он решил написать книгу о личной эффективности. Теперь эту книгу знают все, она называется «Семь навыков высокоэффективных людей». Она считается классикой, постоянно переиздается во всех мыслимых странах мира, за годы существования продано несколько десятков миллионов экземпляров. Сам Стивен Кови настолько разобрался в личной эффективности, что его личными консультациями не преминули воспользоваться несколько президентов, в т.ч. США.

Книжка хорошая, объемная и вдохновляющая. Уроки и принципы, изложенные в ней, часто встречаются у более поздних авторов книг и курсов. Ссылки, правда, забывают сделать, ну да ладно.

Но я не про книгу хочу поговорить, а про неожиданное открытие, которое сделал Стивен Кови, когда ее писал. Он это явление назвал «социальный аспирин».Читать полностью »

В разработке всё дело в творчестве, не так ли? Это искусство, а не наука. Мы, разработчики, решаем сложные задачи, и зачастую наши решения совершенно не очевидны. Мы экспериментируем, внедряем новшества, исследуем и расследуем. Чтобы делать всё это, мы разговариваем. Мы вместе сидим в переговорках, конференциях в скайпе или каналах в слаке; мы обсуждаем свои решения; мы спрашиваем мнения коллег; мы спорим о лучших идеях. Без сомнения, совещания — ключевой компонент современного проектирования ПО… и это очень печально наблюдать.

Хороший архитектор, как и хороший PM, не нуждается в совещаниях и никогда их не организует.

Совещания демотивируют, поглощают время впустую, сжигают деньги и ухудшают качество. Но подробнее об этом — позже. Давайте сперва обсудим альтернативу.

Скажем, я архитектор, которому нужно спроектировать схему реляционной базы данных в новом проекте, у меня есть команда из пяти программистов, и я хочу, чтобы они помогли мне с проектированием. Это очень логичное и адекватное желание, т.к. хороший архитектор всегда обсуждает все возможные варианты с командой перед тем, как принять окончательное решение. Так что, я собираю совещание? Нет!
Читать полностью »