С чего же стоит начать историю про YouTrack 5.0?
YouTrack 5.0 под кодовым названием ‘Gentle’ создан для того, чтобы удовлетворить всем вашим запросам. Теперь YouTrack доступен и на русском языке!
Читать полностью »
Рубрика «agile» - 51
YouTrack 5.0: Твой Язык. Твой Agile. Твои правила
2013-07-31 в 14:58, admin, рубрики: agile, bugtracking, jetbrains, youtrack, Блог компании JetBrains, управление проектами, метки: agile, bugtracking, jetbrains, youtrackАнтипаттерны командного поведения
2013-07-26 в 6:02, admin, рубрики: agile, human resources, воспитание, команда мечты, мотивация, поведение, управление проектами, метки: воспитание, команда мечты, мотивация, поведение 
Уже давно (здесь) я собрал свои наблюдения на тему того, как может проявляться некомпетентность и чрезмерная мнительность руководителей проектов. Пришло время восстановить справедливость и написать о деструктивном поведении участников проектных команд, почему это происходит и как с этим бороться. Поведение человека определяет множество факторов: тип личности, воспитание, роль, мотивация, опыт и много что еще. Не каждое деструктивное поведение следует лечить – «уволить нафиг!». Прежде чем назначать лечение, разумно сначала поставить диагноз. И всегда помним главное правило: все проблемы в проекте – это проблемы менеджмента.
Читать полностью »
Вся правда о модели Пропасти: Ранние рынки и как быть, если вы совершили ошибку
2013-07-11 в 10:49, admin, рубрики: agile, lean startup, mvp, Блог компании ScrumTrek, метки: agile, lean startup, mvp, маркетингМодель пропасти
Всем привет, я бы хотел поговорить о такой вещи как Модель пропасти, Джеффри Мура, которая многим известна, но мне хотелось бы привести примеры и поговорить о нюансах модели.
Сейчас, куда не посмотри, все стали учёные: литературой запаслись, интернеты читают. Кого не спроси, и о кривой принятия технологии знают, и вообще всё им понятно: «… да-да, знаем! Есть Новаторы, Ранние последователи, есть рынок ранний, а есть поздний, отщепенцы и увальни — ну куда без них? Да-да, между рынками, ранним и основным, есть пропасть, которую нужно перепрыгнуть!» Знают. Прыгают. Только, бывает, пикируют. А всё почему? Потому что аннотацию прочли, а содержимое не осилили. Поэтому я написал эту заметку. Речь пойдёт о том, что важные вещи, которые нужно знать о модели Пропасти, не всегда лежат на поверхности.
Сразу оговорюсь — модель работает только при инновациях, прерывающих привычный образ жизни. Если это улучшения линейные, и никак не меняют ваш привычный образ жизни — модель гарантированно не сработает. Читать полностью »
Реформы в IT-отделе. Манифест разработчика
2013-07-06 в 6:47, admin, рубрики: agile, human resources, паттерны, Песочница, Проектирование и рефакторинг, управление проектами, шаблоны проектирования, метки: agile, human resources, паттерны, управление проектами, шаблоны проектированияПреамбула
Я разработчик в небольшой организации. Цель моей работы — делать людям хорошо. Я ускоряю их работу, добавляя тот или иной функционал к уже существующему продукту, моими клиентами являются сотрудники самой организации. Современный бизнес очень динамичен, каждый день появляются новые идеи и потребности, то есть мой план расписан на год вперед, и каждый месяц перестраивается под новые задачи.
Однако, на фоне, казалось бы, динамично растущего бизнеса (кол-во сотрудников увеличивается на 10-15 человек в год) отдел IT растет значительно медленнее. Основное требование к выполняемой работе: “Быстро!”, как следствие плохо масштабируемый код, подверженный плавающим ошибкам.
Сейчас наша компания переживает новый виток развития ПО (период 5 лет), постепенно мы отказываемся от старых разработок и переписываем то, что есть, придерживаясь объектной модели и паттернов, а заодно и переезжаем на новые сервера (новые железо + софт), но требования остались на прежнем уровне — все должно быть сделано вчера.
В очередной раз при релизе кода работа сотрудников была парализована на пару часов, и ген. директор спросила: “Ребята, сколько это еще будет продолжаться?”, на что я ответил: “Когда завершится переезд”, а спустя сутки прислал более подробный ответ, описав то, что меня волнует в последнее время все больше и больше.
Зачем я это рассказываю? А затем, что моя история не уникальна. Кому-то эта статья даст пищу для размышлений, а то и подтолкнет к действиям. Кто-то поделится своим опытом, а кто-то в очередной раз порадуется, что у него в компании все намного лучше.
Читать полностью »
Для начала внедрим Continuous Integration в мозг
2013-07-05 в 18:14, admin, рубрики: agile, continuous integration, tdd, разработка через тестирование, метки: continuous integration, tdd, разработка через тестированиеТот факт, что Continuous Integration нужен, уже никто не отрицает. Вроде бы всем понятно, что собирать приложение, прогонять тесты на регулярной основе очень полезно. Получить быстрый фидбек, найти проблему, прогнать на чистой машине — это все клево. Это понятно и менеджерам проектов, и девелоперам, даже заказчики радуются, когда есть возможность что-нибудь попробовать поскорее.
Менеджер, как человек, который не должен лезть в технические детали, при виде прошедшего Continuous Integration билда, может однозначно сказать, хороший он или плохой. Зеленый — хороший, красный — плохой. Очень простой индикатор, да и не только для менеджеров, но и для всей команды в целом. Девелоперы на эту ситуацию смотрят немного иначе.
Читать полностью »
Основная особенность наших разработчиков
2013-07-04 в 20:51, admin, рубрики: agile, human resources, культурные различия, управление проектами, управление проектами и командой, метки: культурные различия, управление проектами и командойНедавняя статья, сравнивающая русских разработчиков с иностранными навеяла. И мне есть что сказать по этому поводу.
Эта статья переработана из внутренней инструкции, которую я написал для вновь нанятых русскоязычных разработчиков. Для хабра адаптировал, подсократил и убрал излишне категоричные и нецензурные фразы. (Пусть ваша фантазия не жалеет выражений)
Для живости иллюстрирую историями из моей жизни.
По-моему эта статья — самое важное, что я в жизни сделал. Не самое сложное, объёмное или интересное, а важное.
Описываю я тут всего лишь одну особенность русских разработчиков и капитаню по-всякому, но это ключевая особенность, отличающая наших разработчиков, тестировщиков и даже звукорежиссёров, как оказалось. История Макаревича под катом.
Далее: реальные истории из моей жизни, описание проблемы, аргументы, англо-русский ликбез, а также сравнение американских, европейских, японских и наших разработчиков с точки зрения тимлида.
Читать полностью »
Особенности русской разработки
2013-07-02 в 8:27, admin, рубрики: agile, Блог компании ScrumTrek, культурные различия, управление проектами, управление проектами и командой, метки: культурные различия, управление проектами и командой 
По роду занятий я часто общаюсь с различными русскими и западными командами. Очень частый вопрос — есть ли какая-нибудь специфика в работе наших и как это влияет на разработку?
Есть очень неплохая книжка о специфике работы русских вообще. Она называется «Русская модель управления». Ее написал А.П.Прохоров (другой, не олигарх). Не буду ее пересказывать. Основная идея в том, что русские по своей природе могут работать только в двух модах. В нестабильном состоянии они могут свернуть горы. В это время мотивация очень высокая. В стабильном расслабленном состоянии — когда никто не пинает — русские вроде как работают плохо и не сильно утруждаются.
Книга замечательная и действительно многое объясняет в нашей истории. Обязательно прочтите, если не читали. Но я не готов ее рекомендовать как непосредственное руководство к действию. Выводы из нее следуют довольно-таки однозначные и не очень лестные для страны в целом. Однако на самом деле все не так плохо. Наша специфика не является абсолютно контрпродуктивной. Она дает и преимущества и недостатки.
Еще один дисклеймер: на реальное поведение людей действует сложившаяся культура в а) команде б) организации в) стране. Причем именно в этом порядке. Есть «прозападные» компании, где влияние наших культурных кодов очень небольшое. В чисто российских компаниях оно просто огромно. Но реально заметить разницу можно только увидев, как различные культуры сталкиваются друг с другом.
Я буду приводить влияние разных факторов в порядке их важности и силы влияния. Чем выше — тем сложнее это изменить и тем больший эффект это оказывает.
Программирование, Быстрое и Медленное: Разработчики и Психология Самоуверенности
2013-06-07 в 6:05, admin, рубрики: agile, gtd, lean, TSC, оценка времени, оценка трудозатрат, Программирование, стартап, управление проектами, Управление проектомСегодня я собираюсь рассказать о том, что происходит в головах разработчиков программ, в тот момент, когда они делают предварительные расчеты; о том, почему им так сложно зафиксировать все задумки в своей голове; а также о том, как лично я разрешил для себя эту ситуацию, узнал, как жить и писать ПО (для счастливых владельцев бизнеса), но, уверен, мои собственные оценки трудоемкости ненадежны как никогда.
Но сначала история…
Это было <вставьте период времени, который не будет делать меня нелепо старым> в то время, когда я был молодым разработчиком (1). В колледже я был лучшим на занятиях по программированию, будучи младшим разработчиком, я мог взломать код и решить любую поставленную передо мной задачу быстрее, чем кто-либо ожидал. За выходные я мог изучить новый язык и продуктивно на нем работать (или, по крайней мере, мне так тогда казалось).
Таким образом, как и должно было произойти, у меня появился свой собственный проект. Менеджер по работе с крупными клиентами объяснил мне в общих чертах, чего хочет клиент, мы это обсудили, и я сказал: «На эту работу уйдет 3 недели.» «Хорошо», — ответил он. И так я приступил к программированию.
Как вы думаете, сколько времени у меня ушло на этот проект? Четыре недели? Может быть пять?
Мм, вообще-то: три месяца.
У меня остались четкие воспоминания о том времени – мое представление о себе было тесно связано с ощущением, что я — «хороший программист», в чем я сильно разочаровался. Я потерял сон, у меня случались небольшие приступы паники. И этому Не Было Конца. Я помню, что у меня сосало под ложечкой при разговоре с тем менеджером, я снова и снова объяснял, что у меня до сих пор нет ничего, что можно ему показать.
В один из таких черных периодов я решил, что Больше Никогда Не Буду Совершать Подобных Ошибок.
К сожалению, в ходе своей карьеры, я уяснил нечто очень тяжелое: я постоянно совершаю подобные ошибки.
Читать полностью »
Зачем и как мы делаем аудиты
2013-05-21 в 9:47, admin, рубрики: agile, аудит, Блог компании ScrumTrek, инженерные практики, процессы, метки: agile, аудит, инженерные практики, процессыПредставьте, что у вас что-то заболело (не дай бог, конечно). Вы идете к врачу и тут есть две возможности:
- «Резать к чертовой матери!»
- Вы идете сдавать анализы и после этого узнаете, что просто съели что-то не то
Лично мне и мы мои коллегам нравится второй вариант, именно поэтому, когда нас просят внедрить «эти ваши аджайлы», мы проводим аудит. Но мы не такие, как PricewaterhouseCoopers — мы лучше, мы неформальные и мы даем ценные результаты. Как именно — читайте под катом!
Читать полностью »
Бизнес студии: про этапы, деньги, калькулятор и канбан
2013-05-15 в 8:44, admin, рубрики: agile, бизнес студии, бизнес-процессы, продажи в веб-студии, управление проектами, управление студией и проектами, эффективность, метки: бизнес студии, бизнес-процессы, продажи в веб-студии, управление студией и проектами, эффективность 
Я очень ленив, чтобы серьезно заниматься риск-менеджментом. Всегда считал это полной чушью, созданной неудачниками для отмазок в стиле: «А! Мы же говорили, что у вас ничего не получится!» Вон из моего проекта!
Кроме того — мы применяем аджайл. Мелкие итерации. И наши риски, и риски клиентов — ничтожно малы! А еще у нас есть типовые и четко очерченные в договорных отношениях этапы (не путать с agile-итерациями ;). Каждый раз, когда мы сталкиваемся с неопределенностью — мы разбиваем задачу на несколько мелких этапов и наши риски снижаются. Это же просто! Да? А теперь плохая новость:
Снижая риски добавлением этапов, мы снижаем рентабельность* всего проекта.
Свою рентабельность, в смысле. Когда я обнаружил это с помощью простой excel-таблицы, и посчитал, во что обходится добавление еще одного этапа — я присвистнул.
Итак, у нас есть абсолютно типовые этапы:
Читать полностью »