�ݺ�ߣ

Editor's Notes

• #2: на этом докладе вы услышите о моем небольшом опыте внедрения гибких методолгий вне сферы ИТ. Вы услышите как преобразилось ведение дел и проектов у одной небольшой проектной строительной организации после того как они узнали о данной методологии. Для меня это был производственный експеримент, для организации же практически панацея, ибо появился я как раз в период наибольшего напряга в их работе. Ну вот как-то так. Приступим.
• #3: Началось всё с того, что я с одним товарищем начали снимать квартиру вместе, и выяснилось что он постепенно из фрилансера становится учредителем организации которая занимается проектированием и ведением строительных проектов. В наличии имелось три проектанта, которые в последнее время постоянно работают вместе над своими проектами, проектов бывает как сейчас 5 на троих, бывает и меньше. Учредитель и лидер команды практичеки все решения принимает сам, два товарища выполняют свою работу, принимают активное участие в обсуждениях и принятии решений, но менеджер их пропускает все связи через себя. С таким количеством проектов это сложно как оказалось. И таким вот образом наш менеджер превращается постепенно в менеджера-снежинку как было сказано в одной известной презентации Славы Панкратова. Ему это не нравится, но он не знает что делать. Именно поэтому он ко мне и обратился, ибо знал что я занимался проектами и немного просветлен в теории и практике данного вопроса. Кроме этого в данной организации не было понятия общего хранилища задач и требований заказчика. Всё в голове либо на мейле, либо на бумажках.
• #4: А это всё усложняется еще и постоянным изменением настроения заказчика, так же как и в ИТ - а я хочу зеленую кнопочку вместо красной. и в таком духе. Этот момент очень раздувает список задач, и заставляет постоянно его актуализировать и корректировать. Вот с этого мы и начали свое внедрение: ввели понятие Product Backlog. И не поверите, сразу жить стало проще. Не намного конечно, но всё же общее хранилище задач с расставленными приоритетами помогает не только программистам, а вообще в любой деятельности даже в личном управлении.
• #5: к капризности заказчиков прибавляется еще и тот факт, что в этих пяти проектах есть еще роли, которые работают на фрилансе. Т.е. просто выполняют работу за деньги. Это и проектанты "на подхвате", которым поручают работу разовую небольшую, это и строительные команды, поставщики, которых как ни странно пришлось тоже учитывать, потому что от времени поставки материалов зависит дальнейшее ведени проекта.  Вот и получается, что количество здач и юзер-стори всё разрастается и разрастается. Возможно с какой-то стороны и не правильно что мы решили включить эту внешнюю деятельность в общий беклог, но в данной ситуации это очень помогло. Это дало возможность проследить зависимости не только по своим задачам, но и по задачам людей которые по факту не в команде.
• #6: из предыдущего слайда те кто знаком с ГТД наверное поняли о чем я говорил когда упоминал про "не свои задачи, которые тоже отражаются в общем баклоге"... Это у Аллена - "в ожидании" или порученные, в разных источниках по разному. Да и мне кажется что всё аджайл управление очень перекликается с ГТД, вот смотрите: продукт баклог - инбокс спринт баклог - активные задачи ну и - следующие действия - ближайший спринт. и так далее, аналогий много.  К тому же не знаю как вам, но на меня после знакомства с ГТД наибольшее впечатление произвела постановка вопроса: "вы не должны ничего держать в голове, у вас всё должно быть записано и зафиксировано в таком виде в котором вы легко сможете это найти и использовать". К этому же я в первую очередь и приучил наших проектантов. У нас сформировалось несколько лоточков с бумагами: Все Следующие действия папочки только две, потому что активные и порученные у нас на доске. Работа с папками происходила следующим образом: Раз в неделю происходит пересмотр Лотка "все" и перебрасывание оттуда задач в лоток "следующие действия". Это упрощает потом формирование списка задач на следующий спринт.