Command Window and Macros in Visual Studio. Part 2

Всем привет.

В прошлой статье я рассматривал работу с командной строкой в Microsoft Visual Studio. Сегодня мы продолжаем ковырять студию и рассмотрим работу с макросами в студии. Одним из самых мощных инструментов для автоматизации работы.

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

У нас на проекте для сборки игры используется Nant. Тем кто не знаком с этой системой советую ознакомиться. А пока небольшая вводная. Nant  это система, которая позволяет выполнять из командной строки различные команды. Реализован он на С# и доступен вместе с исходниками. Но основным достоинством Nant является широкий набор команд, а также возможность писать свои собственные команды на любом скриптовом или компилируемом языке, главное чтобы этот скрипт или скомпилированное приложение можно было выполнить из командной строки. 

У нас на проекте с помощью Nant собирается все, начиная от артовых ресурсов и заканчивая исходным кодом. Соответственно есть команды BuildGameCode, BuildGameAnimation, BuildLevel  и т.д.

Для конфигурации команд используется конфигурационный xml файл. 

Единственное неудобство, что пишу код я в студии, а вот для запуска команд приходиться использовать что под руки попадется. Одно время запускал просто из виндовой командной строки, потом использовал Luancher, потом использовал Notepad++. Правда в последнем случае кодировать тоже приходилось в блокноте, что не всегда удобно. 

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

Использование макросов имеет несколько неоспоримых плюсов:

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

Но как всегда есть и несколько минусов:

• писать макросы можно только на Visual Basic .Net
• макросы это единичные команды - они хороши когда нужно выполнить быстрое, конечное действие, но когда вам нужно, что постоянно выполнялся некий процесс в фоне, то лучше использовать плагины

И еще один момент, который я пока не могу занести в минусы - это создание диалоговых окон. Предположим вы хотите, чтобы при вызове вашей команды открылось диалоговое окно (которое вы предварительно задизайнили) потом вы ввели некие значения в поля окна и нажав клавишу "Enter" получили результат. Так вот я не знаю, можно ли создавать свои окна, не успел проверить. 

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

Следующая возможность, которую я хотел получить от макросов, это возможность снипетты, которых нет в студии ни для С++, ни для Lua. 

С макросами этот момент также оказался достаточно простым. Я создал текстовый файл, некий шаблон, в котором есть специальные символы $1, $2 и т.д. При вызове команды, текст из файла вставляется в код и символы заменяются параметрами, которые были переданы в команду. Вот и у нас есть снипеты. 

Всем доброй ночи. 

360: смотри да оценивай

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

Методика 360 ориентирована на то, чтобы получить максимально объективную оценку сотрудника. Основное достоинство «круговой оценки» в том, что она позволяет получить полную картину личностных и профессиональных качеств, знаний и умений сотрудника.

 Ключевые моменты методики:

 Сотрудника оценивают:

• Подчиненные
• Коллеги (те кто находиться на одном уровне иерархии с сотрудником)
• Руководство
• Клиенты (не обязательно)

Оценивание анонимное, при этом указывается только к какой группе оценивания принадлежит тот, кто дает оценку (коллега, подчиненный и т.д.)

Методика позволяет оценить в первую очередь личные и профессиональные качества сотрудника (лидерство, коммуникацию, заинтересованность, инициативность, командность, стабильность работы, качество работы, профессиональный уровень и т.д.) и не предназначена для оценивания уровня знаний (языка программирования, технологии и т.д.)

Оценка проводится раз в полгода/год

Как работает:

1. Для каждой должности определяется свой набор наиболее важных компетенций, качеств (5-15)
2. Для каждого качества определяется свой набор идентификаторов, поведенческих примеров (чаще всего 5, иногда 10)
3. Оценщики, которых обычно 5-15 человек, выставляют по каждой компетенции оценку и потом подбивается статистика.
4. На завершающем этапе результат доноситься до сотрудника и составляется план развития 

Например:

Компетенция – инициативность

Критерии

1. никогда не проявляет инициативу, явно уклоняется от принятия решения по вопросу своей компетентности;
2. инициативу для достижения поставленных целей проявляет крайне редко или проявляет неадекватно решаемой задаче;
3. проявляет разумную инициативу для достижения поставленных целей;
4. стремится постоянно проявлять разумную инициативу, не ждет указаний, инициирует действия;
5. высокая степень проявления инициативы, в любой ситуации ищет и находит творческие подходы для достижения поставленных целей

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

 Ресурсы, где можно ознакомиться с методикой 360 более подробно:

• http://nsk.erabota.ru/info/articles/?id=5470
• http://nsk.erabota.ru/info/consult/?id=2035
• http://www.management.com.ua/hrm/hrm049.html

Для меня остались еще открытыми 2 вопроса:

1. Есть ли какой-то софт для автоматизации работы по данной методике?
2. Как проводить ежедневное оценивание подчиненных. Например есть у меня команда человек на 5. Каждый день кто-то отличается в плохую или хорошую сторону, а память она ведь дырявая. Как отмечать успехи своих подчиненных? Ведь такая информация была бы полезна, чтобы отслеживать развитие, направлять и помогать своим подчиненным. 

А что вы по этому поводу думаете? Буду рад услышать кто как оценивает коллег, подчиненных.

Всем доброй ночи

Kanban vs Scrum

Привет всем. 

Сегодня тема не совсем соответствует названию сайта, но я думаю что с автором мы договоримся. 

Последнее время набирает популярности новая техника управления проектами под названием "Канбан", которую как обычно придумали японцы. Вот уж до чего непоседливые. Сегодня я попытаюсь немного рассказать о канбане.

Для начала посмотрим, что нам говорит Вики по поводу канбана. 

Канбан (камбан) — система организации производства и снабжения, позволяющая реализовать принцип «точно в срок».

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

Вот ссылочка на книгу: Scrum и Kanban: выжимаем максимум от Хенрика Книберга и Маттиаса Скарина. Книга на русском и помогает сделать первый шаг в понимании того, что такое канбан. 

Если кратко, то канбан работает во многом аналогично скраму, т.е. присутствует доска, standup митинги, много общения между разработчиками и т.д. Самое главное, что как и в скраме существует ограничение на количество работы, которую команда может делать в определенный момент и никто не может поменять это объем работы. 

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

Например у нас есть команда: 5 программистов. Ставим ограничение на количество задач в 9. Дальше у нас есть проект с набором задач, количество которых конечно же огромно. Лид (продюсер, владелец продукта) выбирает первые 5 задач и программисты начинают работать над ними. И вот по каким-то причинам они не могут закрыть ни одну из задач, тогда программист, который заблокирован приостанавливает свою задачу и берет новую у лида. Таким образом в работе оказывается уже 6 задач. Если у команды накапливается 9 незакрытых задач, то она больше не может брать новые задачи, а должна во что бы то не стало закончить хотя бы одну из уже взятых задач. Такой подход позволяет увидеть проблемы проекта очень быстро, поскольку мы обязаны завершать все задачи, чтобы получать новые и если где-то образуется затык, то вынуждены его исправлять, а не откладывать на будущее. 

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

Когда же такой подход наиболее приемлем? На каком проекте или на какой стадии проекта?

Я для себя нашел как минимум один тип проекта, когда можно применять такой подход. Это багафикс. Многим из вас наверное приходилось работать на проекте в период багафикса и вы знаете, что скрам при багафиксе работает не очень хорошо. Основная проблема для скрама - это отсутствие фиксированного объема работы, которую можно оценить и взять на спринт. Ситуация меняется каждый день, приходят задачи, которые нужно сделать вчера, начальству плевать на ваши попытки объяснить "что спринт и скрам и вообще..." и весь спринт летит к чертям.

А вот  для канбана здесь никаких проблем нет. Мы определяем некий лимит багов на команду и вперед. Команда может отреагировать на любые изменения и проблемы в тот же день когда они возникли и ваш шеф ходит, и всем хвастается, что у него все на мази, и все идет отлично.

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

Единственное, что упустил, это слабые стороны и недостатки канбана. Оставлю это вам и буду рад услышать ваше мнение. 

Всем доброй ночи.