Agile *

Когда на предприятии затевается внедрение информационной системы, особенно силами внешнего подрядчика, то почти всегда говорится: самое большое препятствие – это люди. Сама система, кодирование нового функционала, обучение – это просто трудозатраты. А вот преодолеть саботаж внедрения, переломить мышление, особенно руководителей, заставить выйти из зоны комфорта старой системы (даже если она ужасна) – это действительно трудно. Причем, внедренцы обычно говорят: основная работа по «изменению людей» должна лежать и лежит на заказчике.

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

Ввиду блокировок телеграма, актуально было бы написать про Atlassian Stride, как мы на него перешли, и с какими прелестями решения от любимого Atlassian столкнулись.

Atlassian Stride был запущен в ноябре 2017, как замена облачному HipChat. Де-факто, основной конкурент, это, конечно же, Slack. Я постараюсь сравнивать Stride со Slack, и Telegram со стороны текстовой переписки.

Плюсы

Встраивание в Экосистему Atlassian, контроль за пользователями

Самый большой плюс, это, безусловно, бесшовная интеграция в экосистему Atlassian. Есть у вас jira, confluence — и единый аккаунт у пользователя, где вы можете управлять доступом к разным кускам и возможностям этих двух приложений. А теперь у вас есть третье приложение — Stride, и управление пользователями чатика доступно из той же админки.

Надежда Мецкер, Senior QA, DataArt

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

Первое, о чем я расскажу, это Feature Demo — процесс, в ходе которого мы демонстрируем новый функционал приложения внутри своей же команды. Мы рассматриваем, как именно он был сделан, что получилось особенно удачно, а где можно было сделать лучше. Уже после общего рассмотрения и окончательного одобрения функционал может уходить в продакшн.

Под катом обзор и выводы с ретроспективы MeetUp-а про командную работу и рефлексию, который 3 апреля провела Елена Литвинова.

Для меня он стал демонстрацией как обычная команда (далее команда 1.0), отличается от подготовленной (команда 2.0).

Подготовленная означает, что большинство членов команды не просто знакомы с практиками и ценностями Agile, но владеют ими.

Всем привет!

Сегодня у нас на связи agile-коуч Василий Савунов. Немного поговорим об организации работы команды по системе Scrum, а также получим ценные рекомендации по обучению Scrum и Kanban.

Какой «золотой молоток» пытаются применить к разработке инновационных продуктов в российских крупных компаниях? В последние 5 лет на рынке существует тренд на внутреннее корпоративное предпринимательство (Inner Corporate Venture, далее ICV), и большинство крупных компаний бесстрашно начинают внедрять новые подходы к ведению бизнеса и создают специально для этого инновационные лаборатории, команды и подразделения. В обиход входят такие понятия как MVP (Minimum Viable Product — минимально жизнеспособный продукт), Lean Startup (бережливый стартап) и др.

Мы запускаем новое направление Университетов DataLine — семинары по поддержке интернет-проектов и взаимодействию разработки и эксплуатации.

Новым будет и формат — теперь мы будем вести онлайн-трансляции со всех наших семинаров!

Дата: 22 марта в Москве.
Тема: «Разработка vs Эксплуатация. Почему ни Agile, ни DevOps – это не волшебная пилюля, и как с этим жить.»
Ведущий курса: Алексей Приставко, директор по веб-проектам DataLine.

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

UPD от 18-08-2018: обновил и упростил текст статьи

Agile — это концепция управления проектами, которая базируется на гибкости и максимальной адптивности к изменениям. Можно сказать, что суть аджайла заключается в принципе «проверять и адаптироваться». Можно и нужно как можно чаще внедрять небольшие готовые вехи продукта, чтобы понимать, создается ли именно то, что нужно рынку и потребителю — вот к чему призывает аджайл. Аналитика рынка и потребностей потребителя проводится часто, чтобы подкорректировать планы по развитию проекта. Программисты пишут проект короткими итерациями, что позволяет владельцам бизнеса проверить «на бою» свои бизнес-идеи. Учитывая, что некоторые фичи были нужны еще вчера, а взятые на прошлой неделе требования уже устарели, то каждый участник проекта должен быть всегда готов к изменениям. Разработчики, как и владельцы продукта, в идеале понимают весь процесс поставки продукта потребителю и ту выгоду, которую он решает. Многие говорят, что аджайл работает, некоторые считают, что он собрал просто лучшие практики разработки ПО, не создав ничего нового, однако нельзя отрицать, что аджайл работает. Это доказывают истории компаний [1]

Всем привет!

Приближаемся к запуску нового нашего курса: «Автоматизатор в тестировании». Сегодня вот последний открытый урок, потом день открытых дверей и в бой.

На прошлых двух таких мероприятиях не раз задавался вопрос о связи Agile и автоматизации. Вот, нашёлся в закромах неплохой и не сильно большой материал, которым с вами и делимся.

Поехали.



Тестирование программного обеспечения, следующее принципам agile-разработки, называется Agile Тестированием (Agile Testing). Agile — итеративная методология разработки, при использовании которой требования развиваются в ходе сотрудничества между клиентом и самоорганизующимися командами и гибкого согласования с потребностями клиента.

Когда существуют варианты – важно не ошибиться и изучить все детали и возможности, чтобы остановиться на лучшем. Выбирать между методами управления разработкой не всегда просто, особенно если это Scrum и Kanban.

Лучше зажечь одну свечку, чем проклинать темноту.

За последние 24 часа, две мои статьи «Почему ваш программист просто хочет кодировать» и «Менеджерам пора проснуться» прочитаны более 96 000 раз на Medium и получили более 900 комментариев на Reddit.

Похоже, проблема серьёзнее, чем я думал.

Да, в технологических компаниях есть плохие менеджеры. И да, я жёстко обошёлся, возложив на них вину за апатию разработчиков.

Но я хочу помочь разработчикам, которые чувствуют себя разочарованными, бесправными или лишёнными права голоса. Ведь именно вы разместили подавляющее большинство комментариев, описывающих ужасные условия и ужасное управление. Вы подняли руку, чтобы сказать: «Мне это надоело».

Кажется, что гештальт подход в психотерапии и гибкие методологии разработки очень близки. Это статья — попытка развернуть эту мысль, имея в виду читателей habra. Что такое agile здесь должно быть понятно, а вот что такое психотерапия вообще и гештальт-подход в частности наверняка требует пояснения. Разобравшись с тем и другим, можно посмотреть на знакомые вещи под новым углом и, как всегда, что-нибудь понять про себя, про мир и ещё что-нибудь.

Disclaimer: Статья Мартина Фаулера была опубликована в 2003 году

в журнале IEEE Software. В сети (но не на Хабре) есть замечательный перевод пятилетней давности от Сергея Теплякова (SergeyT).

Недавно я встретил в коридоре явно раздраженного коллегу, Дэйва Райса (Dave Rice). Мой вводный вопрос вызвал резкое заявление: «Нам надо игнорировать любого кандидата, имеющего пункт «Архитектор» в резюме». Смущало в этой странной фразе то, что мы же сами, обычно, представляем Дейва как одного из наших ведущих архитекторов.

Причиной его «титульного психоза» являлся тот факт, что по меркам даже нашей индустрии, смысл слов «архитектор» и «архитектура» чрезвычайно переоценен. Многим кажется, что к термину «архитектор программного обеспечения» отлично подходит тот самодовольный и все контролирующий образ из финальных сцен «Матрица: Перезагрузка». Но даже в компаниях относящихся с большим презрением к такому отображению, все равно, существует жизненно важная роль технического лидера, в сущности – архитектора, такого, как сам Дейв.

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

Предисловие

Данная статья очень субъективна и основана на моём опыте в ИТ-индустрии (Я разработчик с 10-и летним стажем и опытом работы в различных проектах, командах и странах (Казахстан, Канада)). Уверен, что многие не поддержат мою точку зрения и могут назвать эту статью «плачем динозвара», но всё-же хочу поделиться ею…

Что такое DevOps

Согласно википедии DevOps набор практик, нацеленных на активное взаимодействие специалистов по разработке со специалистами по информационно-технологическому обслуживанию и взаимную интеграцию их рабочих процессов друг в друга. Т.е. это попытка масштабировать Agile весь процесс разработки ПО включая внедрение и сопровождение. Основное назначение DevOps-а — увеличение частоты релизов и повышение ответственности команды за продукт. Звучит идеально… как и любые маркетинговые слоганы…

С моей точки зрения основная задача DevOps — снижение затрат для бизнеса (что хорошо, но часто это идёт в ущерб качеству продукта).

Пару-тройку лет назад мы тоже с энтузиазмом взялись переходить на гибкие методологии разработки, а по-простому: внедрять Agile. Наняли внешних консультантов, выделили для обкатки процесса кусочек большого продукта, с воодушевлением начали быстро и качественно делать. Делали-делали, а потом поняли, что получается какая-то ерунда, а не Agile, как в том анекдоте про секретаршу и 1000 знаков. И вроде бы все молодцы, работают как раньше, люди опытные, и продукт работает, только всё как-то «не по Agile-у».

Мотивация в команде упала. Заказчики в растерянности от того, что предполагаемые «волшебные» сроки не сбываются, и вообще заявляют, что Agile не место в приличном обществе. В результате маленькая группка «Agile-трансформаторов» села и устроила мозговой штурм, почему же у нас ничего не выходит? Начали выписывать любые мешающие нам ограничения. Их оказалось очень много, и мы назвали их драконами.

Приветствую, коллеги. Сегодня я хочу поделиться с вами своей мечтой.

Я работаю в сфере разработки ПО примерно 12 лет. За это время я сменил более 10 организаций. Были только два места, где я задержался надолго — на 3 и 5 (привет, Валера) лет, а в остальных компаниях я отработал от двух до восьми месяцев.

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

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



Под катом — полный драматизма рассказ о попытке внедрения гибкой методологии управления в крупной enterprise-компании.

Да много где: Омск, Томск, Красноярск, Барнаул и, конечно, столица Сибири — Новосибирск, где ежегодно проходит крутейшая за Уралом ИТ-конференция CodeFest.

Каждый год на CodeFest слетаются 1500—2000 айтишников, обеспечивая тем самым всю туристическую выручку Новосибирска на несколько месяцев вперёд.

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