Нашей компании уже 6 лет. Она была основана на принципах agile и росла на них. Мы использовали Extreme Programming с самого первого дня, добавили немного Scrum позже и в конце концов переключились на Kanban. Хочется поделиться бесценным опытом и рассказать об изменениях нашего процесса разработки за последние 4 года.

Давайте познакомимся с новыми инструментами планирования, появившимися в TFS 11 Beta, которые можно использовать в разработке Windows, Web, мобильных, облачных и кросс-платформенных приложений.



Так как TFS позволяет использовать несколько шаблонов процессов для поддержки разных методологий организации процесса разработки, мы сначала рассмотрим только один из них, наиболее популярный SCRUM.
Для знакомства нам могут понадобиться: образ виртуальной машины, руководства к лабораторным работам, практическое занятие на русском MSDN или данная статья – на выбор.

План захвата темы:
• Описание требований (Backlog)
• Планирование итерации
• Планирование работ
• Загруженность исполнителей

Доброго времени, хабравчане.

Хочу поделиться наблюдениями возникшими в процессе проведения трека «Usability Engineering & Ubiquitous Computing on mobile devices» который проводился в рамках совместной российско-немецкой студенческой школы JASS-2012 о которой уже писали на хабре. Однако, в отличие от предыдущего поста я буду описывать школу глазами организатора.

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

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

Инициация проектов

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

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

Как менеджер проектов в своё время я попытался интегрировать различные Agile/SCRUM методики в свою повседневную жизнь. Ведь она тоже в каком то смысле является долгосрочным и довольно динамичным проектом.

Неоднократно пробовал использовать популярные GTD инструменты, но в итоге именно Google календарь ввиду своей наглядности и привязке ко времени — оказался наиболее эффективным. Получается такой вот Self SCRUM Board с итерациями и планерками :)

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

Теперь хочу подробно разобрать пример построения контрольной карты Шухарта на основе реальных данных. В качестве реальных данных я взял историческую информацию о завершенных личных задачах. Эта информация у меня есть благодаря адаптации под себя модели личной эффективности Дэвида Аллена Getting Things (про это у меня тоже есть старый слайдкаст в трех частях: Часть 1, Часть 2, Часть 3 + Excel-табличка с макросами для анализа задач из Outlook ).

Постановка задачи выглядит так. У меня имеется распределение среднего числа завершенных задач в зависимости от дня недели (ниже на графике) и нужно ответить на вопрос: «есть ли что-то особенное в понедельниках или это всего лишь погрешность системы?»



Ответим на этот вопрос при помощи контрольной карты Шухарта – основного инструмента статистического управления процессами.

Не могу не опубликовать размышления от Тани Васильевой по поводу предстоящей 5-6 марта CSM сертификации в Петербурге. Не поспоришь!

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

«Я могу быть не согласным с Вашим мнением, но я готов отдать жизнь за Ваше право высказывать его» (Ф. Вольтер)

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

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

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

Недавно дошли руки до превращения записи моего доклада на AgileKitchen в полноценный слайдкаст.

По моему опыту, в Agile-командах процент собираемых метрик, использующихся для принятия управленческих решений, заметно выше, чем в командах, следующих более консервативным моделям разработки. Однако нужно понимать, что каждое измерение неизбежно содержит в себе ошибку. Перед тем, как принять то или иное решение на основе «аномалий» в наблюдаемых значениях, было бы не плохо понять, что стоит за этой «аномалией»: некоторая особая причина, требующая реакции со стороны руководства, или такое поведение является нормальным для рассматриваемой системы?

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