Как же приятно получать такие отзывы: «Дмитрий, спасибо за тренинг. Применения в работе полученных знаний нашла. В первую очередь, начала с себя, изменила свое отношения к работе, к команде и клиентам/заказчикам в сторону большого взаимодействия и выстраивания доверительных отношений между всеми участниками проекта. Стараюсь вести проекты максимально открыто, т.е. заказчик … Continue reading →
На моем тренинге Certified Agile Professional мы много времени уделяем формированию навыка проведения глубинного анализа проблем, перед тем, как приступить к их решению. Это позволяет находить корневые причины проблем и вырабатывать контекстные решения для них, устраняющие проблемы на системной основе. В то время как исходная проблема чаще всего является просто … Continue reading →
– Дмитрий, у меня такой вопрос. Предположим, мы хотим внедрить Scrum, и знаем, что Scrum – это фреймворк, то есть мы можем брать какие-то инструменты, какие-то не брать. Ты говорил о важности ретроспективы. Ты бы мог сказать, какие обязательно нужно взять инструменты, а от которых можно все-таки отказаться? – Да. … Continue reading →
Большинство людей воспринимают Agile как набор практик и инструментов, которыми можно просто взять и дополнить свой текущий процесс разработки. Тем самым, решить имеющиеся проблемы со сроками, с недовольством бизнеса, с качеством, с мотивацией и тп. Те, кто уже пробовал так сделать, знают, что это не работает. Конечно, определенные улучшения процесса … Continue reading →
На прошлой неделе на конференции AgileDays’15 рассказывал, как мы проводим культурную трансформацию подразделений разработки в крупных банках. Когда недостаточно менять только процессы, это не даст значимого эффекта. Потому что множество проблем лежат за рамками проектных команд или отделов. Нужно менять привычки, ценности и поведение людей — то есть, культуру компании … Continue reading →
Как вы знаете, индустрия разработки программных продуктов почти все время своего развития была сосредоточена на более гарантированной, более быстрой поставке ожидаемого результата бизнесу. Если в 1970 году была придумана каскадная модель разработки (1976 — появился термин “водопад”), с ее годичными циклами релизов (раньше не умели выпускать быстрее), то уже в … Continue reading →
Сегодня было интересно — начинаем процессные изменения в Российском ИТ подразделении одного из международных банков. Одна из целей изменений — вовлечение рядовых сотрудников (аналитики, разработчики, тестировщики) в более тесные отношения с бизнесом, чтобы научились помогать решать реальные проблемы заказчиков, а не просто выполняли поставленные и утвержденные заявки «как есть». Вообще, … Continue reading →
Продолжая разговор про требования, начатый в предыдущем посте о декомпозиции требований, хочется теперь поговорить про их приоритезацию, поскольку это краегольный камень абсолютно для каждого проекта. Представьте проект, который длится уже, например, несколько релизов. В нем скопился целый ряд новых, еще не реализованных требований заказчиков (причем, требований крайне важных и срочных!), … Continue reading →
Один из самых интересных вопросов, возникающий в любой компании при внедрении agile, является декомпозиция требований. Не верите? Попросите своего коллегу аналитика рассказать вам о любом своем недавнем требовании, которое невозможно разбить на отдельные части и можно сделать только целиком? Как правило, чем крупнее компания, тем большим по размеру будет это … Continue reading →
Мы очень много работаем с компаниями в России, команды в которых так или иначе используют (или только собираются использовать) Scrum в качестве основы для своего процесса. «Скрам очень прост для понимая, но очень сложен для внедрения» — так говорят сами его авторы, и это правда. Более того, в скраме есть … Continue reading →