Agile *

Является ли Agile аналогичным Lean? Когда люди говорят “Agile”, подразумевают ли они на самом деле Scrum? Или люди все еще используют разные типы Agile и почему?

Получая много вопросов в прошлом, я решил расставить все точки над “и”.

Большинство людей не умеют адекватно оценивать сроки выполнения задач. Ой как это заставляет порой понервничать… Тут и «дэдлайн подкрадывается незаметно». И перестраховка в 500% на всякий случай (все равно не хватает). И отжимание «заведомо раздутых сроков», чтобы исполнитель пообещал чего-то более приемлемого. И невнятные бормотания вместо конкретных цифр.



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

На этой неделе мы постарались системно рассмотреть, кто, зачем и как проектирует UX. Сегодня мы решили продолжить эту тему в свете редизайна нашего сервиса Печкин-mail.

SCRUM — фреймворк управления проектами, в который наша команда попробовала внедрить этап тестирования. В этой статье мы хотим помочь не совершить наших ошибок тем командам, которые только начинают знакомиться со SCRUM. Участники же опытных SCRUM-команд приглашаются в комментарии, чтобы поделиться замечаниями и успехами. А в качестве иллюстраций — беговые дорожки, марафонцы, препятствия. Они тут неспроста. Да и Олимпиада же, в конце концов.

Этот материал будет полезен в первую очередь тем, кто много занимался программированием и вдруг внезапно стал вынужден заниматься управлением проектами и людьми. С год назад я рассказал про наказания на конференции, а солнышки из Битрикса сделали текстовую версию для #habr. К сожалению, потеряв в точности, четкости и правильности акцентов. За год материала добавилось. В конце — чеклист для ленивых :)

Итак. Если вы не садист или моральный урод, а ваши сотрудники — не мазохисты, то сомневаюсь, что кому-то из вас наказания доставляют удовольствие. Мне — нет.

Структура публикации

• Немного о том – почему так?
• Схема работы команд разработки под которую делается настройка
• Настройка XML-ек
• Сохранение XML-ек
• Настройка TFS через интерфейс

Использовалась TFS 2015, однако многое справедливо и для более ранних версий.

В минском офисе Wargaming регулярно проходят встречи, на которых сотрудники компании делятся опытом и обсуждают насущные вопросы, волнующие разработчиков, менеджеров, дизайнеров, продюсеров, художников – словом, всех тех, кто работает в IT и геймдеве. Эти митапы мы называем WG Talk и проводим в закрытом формате, только для сотрудников компании.
Но есть темы и знания, которыми нельзя не поделиться с широкой аудиторией. Поэтому мы организуем Open WG Talk.

Сегодня мы хотим поделиться с вами видеозаписями выступлений последнего Open WG Talk, темой которого стало продуктовое управление и внедрение новых процессов. Под катом вы найдете доклады Сергея Бережного, директора разработки Wargaming, и Ярополка Раша, руководителя медиасервисов Wargaming.



Приятного просмотра!

Здравствуйте, уважаемые читатели.

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



В статье, текст которой вас ждет под катом, мы перевели «User Story Mapping» как «визуализация функционала». Вариант взят из очень интересной книги Бориса Вольфсона "Гибкое управление проектами и продуктами", также выходившей в нашем издательстве.

Итак, автор статьи прочитал труд Паттона и решил, что так должен поступить каждый. Насколько убедительные примеры он привел — судить вам.

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

Эта статья — выражение моей личной боли. Кнопочные решения портят мне жизнь, я трачу время на споры и обоснования.

Когда мы общаемся с коллегами, заказчиками или пользователями, я использую фразу «кнопочное мышление». Что я имею ввиду под этим термином? Текущая статья — развернутый ответ на этот вопрос.

Синонимами кнопочного мышления я считаю «экранное мышление» или преждевременную концептуализацию. Я раскрою мышление кнопками на десятке примеров из практики. А здесь для начала история, которая наверняка случалась с каждым. Представьте к вам приходят и рассказывают о падении конверсии на сайте. А вы ему сразу: «Давайте кнопку покупки сделаем побольше и поярче!». Что произошло? В бизнесе возникла проблема. Вместо погружения в детали, вместо исследования причин, вы играете с размерами кнопки. Вот в таких случаях я говорю о кнопочном мышлении.

Для тех, кто любит смотреть, а не читать, есть видео и слайды.

Когда у нас надёжно заработала непрерывная интеграция на Jenkins и устоялись процессы выпуска релизов продукта, возникла мысль: а почему бы не перенять передовой опыт и не поставить в офисе свой электронный излучатель информации (information radiator): большой красивый экран, на котором автоматически отображаются происходящие с проектом процессы?



Мысль хорошая, но ведь это стоит денег и времени, т. е. того, чего никогда нет. Особенно сейчас. Особенно у маленьких компаний без бюджетов на всевозможные вспомогательные цели. Сделать всё предстояло за «пять копеек» и за «пять минут» — и вот как я с этим [частично] справился.

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

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

Даже относительно крупным компаниям приходится перестраиваться. «[В последнее время] заказчики выводят на конкурсы любые независимые этапы, по окончании которых можно получить завершенные бизнес-результаты (оптимизация части инфраструктуры в ключевых регионах, рост быстродействия критичных для бизнеса приложений, таких как «1С»)», – рассуждает директор департамента ИТ-аутсорсинга ALP Group Дмитрий Бессольцев.

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

На мой взгляд самую коварную ошибку допустили создатели, когда сказали, что скрам это фрэймворк, который нужно адаптировать под себя. Я много раз слышал, как люди ссылаясь на это утверждение, оправдывали отсутствие или модификацию фундаментальных элементов скрама, таких как роль Product Owner, burndown диаграмма, цель спринта, демонстрация, готовый продукт в конце спринта и др. Для таких многочисленных «адаптаций» даже появился специальный термин «Скрамно» (ScrumBut).

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

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

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

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

Данный текст был создан сугубо ради существования постоянной ссылки, которую бы сам автор, да и все вы — могли бы смело отправлять своим будущим заказчикам, коллегам, родственникам и знакомым в виде стандартизированного ответа на вопрос: «А надо ли мне ваше ТЗ и вообще что это?»

Как говорится — «вместо тысячи слов», поскольку каждый раз евангелистить по 4-5 часов в скайпе на данную тему становится уже утомительным, а общемировая тенденция подсовывать под определение «Технического задания» откровенную ерунду с годами все только усиливается.

Недавно, в ходе «курса молодого бойца коуча», который предполагает прохождение новыми сотрудниками всех тренингов компании ScrumTrek, я побывал на тренинге Управление требованиями в Agile-проектах. Ниже расскажу о впечатлениях, которые остались после тренинга.

Чуть больше года назад мы в Wrike начали использовать для планирования метод целей и ключевых результатов (Objectives and Key Results, OKR). Его придумали и впервые применили для в Intel, потом подхватили в Google, Oracle, LinkedIn и Twitter. Метод универсален, хорошо помогает фокусироваться на целях, повышает инициативность и стимулирует работу между разными командами в компании. Плюс его можно отлично реализовать, используя инструменты нашего сервиса, что для нас было одним из ключевых требований.

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

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

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

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

Однако, из той же предыдущей статьи можно узнать, что мозг обслуживает эмоции, правильно объясняя нам что мы тут только что решили. И в таком «холоднорассудочном процессе» как познание действительности все тоже происходит через эмоции, а вовсе не доводы разума.