Agile *

Как обычно в понедельник короткая подборка того, что вы пропустили за выходные.

Как обычно в понедельник короткая подборка того, что вы пропустили за выходные.

Прошлой осенью прошла менеджерская конференция LeanKanban Russia-2014.

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

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



Конференция чисто менеджерская, от поднимаемых тем и аргументов, и местами сильно избитого бизнес-жаргона, у «сферического линейного разработчика» наверняка будет butthur идиосинкразия («WAT?? Процессы? Инновации? Менеджеры-бездельники! Фигли думать, трясти надо!»), но с точки зрения менеджмента — это самые свежие тренды. Так что наверно, в отделенном от хабра мозге мегамозге, обзору будет самое место.

Под катом будет уже краткий обзор, со ссылками на видео и прочие материалы (т.е. не бойтесь открыть страницу, видео не встроено).

Доброго дня. Как обычно в понедельник короткая подборка того, что вы пропустили за выходные.

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

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

Представьте, идёт строительство дома…

Рассмотрим принципы современной организации процесса разработки, в большей степени присущие современным гибким (Agile) методологиям, чем «водопаду» (Waterfall).

Возможно, при этом будет определенный акцент на критике, но не стоит на ней зацикливаться. Скорее, это сравнительный обзор: каждый из подходов имеет свои плюсы и минусы.
Данный пост является продолжением предыдущих публикаций (часть 1, часть 2).

Есть некоторые вопросы по поводу распределения полномочий в управлении проектами и процессе разработки у таких ролей, как аналитики, руководители проектов, архитекторы, разработчики.
Вот некоторые тезисы, затрагивающие задачу обеспечения качества разрабатываемых продуктов, которыми я хотел бы поделиться.

1. Аналитики создают модель предметной области в своих терминах, разработчики программируют ее в своих (в той или иной парадигме программирования).
Нужно, чтобы кто-то «наводил мосты» между первыми и вторыми.

Каждый месяц по всему миру происходят десятки, если не сотни, IT-ориентированных конференций, выставок и других мероприятий.

Во второй раз мы собираем все наиболее интересные международные даты этого месяца для того, чтобы представить читателям Мегамозга в одном месте.

Доброго дня. Как обычно в понедельник подборка того, что вы пропустили за выходные.

В данной статье я бы хотел поделиться опытом использования разных методик управления разработкой (Waterfall, Scrum, Kanban) в компании Acronis и рассказать, чем был обусловлен выбор той или иной методики или практики.

Для начала пара вводных слов. Цикл разработки продукта у нас в Acronis, как правило, длится от полугода до года. В разработке принимает участие команда из 40-45 человек. Сам продукт является системным приложением, а основная разработка идет на C++. Важный момент: продукт должен быть выпущен точно в срок не позднее фиксированного момента времени (да-да, и такое бывает).

Последнее детище нашей компании – ATI, в миру известный как Acronis True Image. Этот продукт довольно давно в разработке – настолько, что мы успели написать о нем на Хабр не одну, не две и даже не три статьи (четвертую найдите сами). Команда разработчиков ATI достаточно внушительная, а потому у нас накопился большой опыт управления подобными проектами.

Итак, когда-то очень давно у нас была классическая «водопадная» модель разработки:
Требования -> Дизайн -> Реализация -> Тестирование и стабилизация -> Поддержка.

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

Анализ работы команды и того, как она была проделана

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

Наверняка многие слышали о системе управления проектами Asana. Дастин Московиц, ранее известный как соучредитель Facebook, привлёк многомиллионные инвестиции для своего проекта.

В начале 2013 года, когда мы всем агентством в очередной раз лихорадочно пытались сбежать из неповоротливых «Битрикс 24» и «Мегаплан». Я протестировал Asana и сказал: «ну что инвесторы нашли в этом проекте? Здесь же ничего нет!» Однако со временем понял: как и любая легендарная система, Asana имеет свою философию, своё ДАО, без знания которых ларчик не откроется.

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

В качестве предисловия

Началось все в феврале 2014 года с приглашения посетить конференцию AgileDays2014. Вечером того же дня я засел на сайте конференции, чтобы выделить интересные мне темы и спланировать посещение докладов. Через 5-10 минут я уже смотрел запись выступления с AgileDays 2013 «Свобода и ответственность» Антона Волкова из Alternativa Platform.

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

Для того, чтобы взрастить чувство ответственности нужно:

• Добровольное принятие ответственности. Например, когда человек сам называет срок выполнения задачи, он принимает ответственность. А если срок спускают сверху ни о каком принятии ответственности речи не идет, она на том, кто спустил срок;
• Свобода выбора — люди в праве решать какую работу брать, выбирать стратегию решения задачи, с кем работать (определяют состав команд);
• Последствия (положительные и отрицательные) от принятых решений, действий и бездействий. Например, сдал качественно выполненный функционал в срок, получил признание коллег и, возможно, дополнительное денежное вознаграждение. Или, допустил баг в продуктовой среде, получи нагоняй и порицание от коллег.

В среду, 4 марта, в московском офисе компании Deutsche Bank состоится встреча с экспертом в области проектного управления Татьяной Беловой. Татьяна расскажет о разнице между КСУП, жизненным циклом проекта и PMBoK.

Как обычно после выходных – небольшая подборка событий, которые произошли, пока вы отдыхали.

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


Иллюстрация: Alamy/PHOTAS
Рис. 1. Заседание руководства проектом Остроконечники и тупоконечники

Воспользуемся сравнительным анализом существующих методик управления проектами, изложенным в монографии Роберта Высоцкого «Адаптивное управление проектами: традиционные, гибкие и экстремальные методики». Седьмое издание этой книги не так давно стало доступным англоязычной аудитории. Насколько мне известно, она еще не переведена на русский язык. А жаль, книга замечательная, видимо не зря на американском Амазоне у нее 4ый рейтинг среди литературы по Аджайлу.

Как обычно в понедельник – небольшая подборка событий, которые произошли, пока вы отдыхали.

Среди ваших знакомых наверняка есть люди, которые попробовали Scrum и решили отказаться. Возможно вы сами были в такой ситуации. Я обучался скраму у Джима Коплина, внутреннего тренера Microsoft, в Швеции. Работал в нескольких компаниях, в которых всё было по скраму. А так же в тех, где использовали классические методологии разработки. В этой статье я расскажу свои наблюдения и постараюсь раскрыть тайну скрама, почему же многим он так и не даётся. Читайте под катом.

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

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

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