вторник, 23 декабря 2008 г.

Scrum и XP: Заметки с передовой



Формальный анонс: "Благодаря инициативе Алексея Солнцева и активистов сообщества Agile Ukraine переведена популярнейшая книга Хенрика Книберга "Scrum and XP from the Trenches".

Неформальный анонс: Ну какие же молодцы, а? Вот говорят, что ПМ’ы ничего не умеют делать…А они умеют. Организовывать и даже самоорганизовываться. Ладно, пусть не все, но некоторые точно могут :-). Да не просто так, а с реальным выхлопом - так пишет об этой инициативе Серега Мовчан, на совести которого 17 переведенных и 89 отревьювленных глав из 110.

Итак, рецепт:
1 - находится группа единомышленников, причём среди них обязательно должен быть как минимум один подорванец
2 - Происходит общение на интересующие народ темы до тех пор, пока подорванец не выдаст что-то наподобие вот этого;
3 - Тут-то надо сразу же подписаться и voilà - дело в шляпе, а у тебя есть чем занять долгие вечера после работы;
4 - Далее идёт 2 месяца более-менее напряженного перевода, 1 месяц тормозов и 1 месяц нервного ожидания от вычитки - чего там филологи сделают с нашим детищем?
5 - И гордое созерцание результата (PDF)… кстати, ничуть не хуже оригинала.

Немного о книге
Книга исключительна полезна. С одной стороны она про такой хорошо (если не излишне) раскрученный термин как Scrum, на который ведутся большинство (если не все) начальников. С другой стороны, она упирает на то, что Scrum без инженерных практик не живёт. Не знаю сознательно ли Хенрик заложил этот месадж в книгу или так получилось случайно, но получилось именно то, что доктор прописал :-)
Почитайте - не пожалеете.





Читать далее...

понедельник, 22 декабря 2008 г.

Протестировано проектом Happy-PM

Вот тут Саша Орлов кидал вызов, который попал в меня :)

Вот тут меня одаривают плюшками в виде лицензии на тестируемый продукт, Блокнота Успешного Менеджера и футболки Happy-PM.

Можно сказать, что первое сотрудничество удалось - оффшорное тестирование продукта состоялось!





Читать далее...

понедельник, 15 декабря 2008 г.

Priority vs Severity

«Умей расставлять приоритеты» - часто слышим мы в повседневной жизни.

«Мы рекомендуем: в первую очередь выполняйте главные задачи! Пометьте их наивысшим приоритетом, и они всегда будут в поле вашего зрения» и «Приоритеты дают возможность индивидуально выделять каждую задачу по важности» написано на сайте одного из продуктов, разработанных для планирования времени, задач и жизни в целом.

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

В дефолтном файле, поставляемым с триальной версией вышеописанного приложения, для ознакомления, есть 3 «приоритета»: must be done, ought to be done, и optional. Что делать в случае, если 2 задачи, которые must be done «кровь из носу», назначены на 1 и тот же день, в таком случае непонятно.

Например, в один и тот же день нужно подать документы на поступление в ВУЗ и документы на приватизацию жилья. По-моему, равнозначно важные задачи, но их очередность нужно строго определить, руководствуясь временем приема чиновников, собственным маршрутом движения или какими-либо ещё внешними факторами.

С рабочими задачами то же самое. Работа – это маленькая жизнь :)

Итак, приоритет (priority) – это атрибут, указывающий на очередность выполнения задачи.

Важность (severity) – это атрибут, характеризующий влияние результата выполнения этой задачи на весь проект (в соответствии с поставленными целями).

В своем планировании времени и задач я использую двойную систему категоризации:
По priority (first, third, second, other)
По Severity ( critical, major, minor, other)

Ведь кайросная задача «проходя мимо поликлиники зайти сделать флюорографию» имеет важность major в проекте «Поддерживать здоровье», но сроки её выполнения могут быть растянуты на неделю, и приоритет у неё other.
В то время как «поговорить с руководителем о расширении моих полномочий в проекте» - задача в проекте «Работа», менее важная, чем «составить отчет для заказчика» потому что и так вроде все неплохо, но руководитель отчаливает в Штаты завтра на 3 месяца, поэтому приоритет у этой задачи first.

Вобщем, как говорится, it depends. Но использование обоих атрибутов существенно расширяет возможности планирования чего бы-то ни было.





Читать далее...

вторник, 9 декабря 2008 г.

Програма дистанционного обучения "Junior QC Engineer"

В октябре руководитель отдела HR предложил мне заняться дистанционным обучением студентов.

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

Ранее подобные практики применялись только к кандидатам в разработчики, и вот решено было начать подобное для тестировщиков.

Я, естественно, тут же согласилась и с полными карманами энтузиазма бросилась составлять для них программу. Сначала я не стала искать в Интернете готовые, а подумала «в каком виде мне хотелось бы получать те знания, которыми я обладаю сейчас». Именно по такому принципу я и построила свою программу. Конечно же а) практика первична, б) все спорные моменты объясняю с точки зрения реальных проектов, почему лучше так, а не иначе, и в каких случаях следует отступить от этого правила, и в) прошу задавать вопросы сразу же, по мере их возникновения.

Когда перед конференцией SQA Days-4 я изучила резюме организаторов и увидела, что Наташа Густыр является автором курса «Введение в тестирование ПО », который она же и читает в московском учебном центре «Интерфейс», то поняла, что мне просто необходимо с ней пообщаться И пообщалась. Результативно – советы были претворены в жизнь.

Кстати, когда я с уже готовой собственной программой, зашла в Интернет и скачала несколько разработанных до меня, я поняла, что попала в десятку :) Все освещаемые вопросы практически совпадали, разнился лишь порядок, да и то – не принципиально. Это не могло не порадовать.

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

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





Читать далее...

среда, 3 декабря 2008 г.

Как лучше обучать новых сотрудников.

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

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

И тут я поняла, что ошибалась. Вот же она, педагогика! Вот они, дети! Значит все-таки мне это может нравиться? И неплохо получаться ;-)

В своей жизни я сталкивалась в двумя подходами к обучению:
1 – делай так, потому что так надо\принято\я_так_сказал;
2 – объяснять истинные причины и показывать достоинства и недостатки того или иного процесса или метода.

Также я интуитивно разделяю методы обучения по структуре на:
1 – индуктивные;
2 – дедуктивные.
Индукция и дедукция – понятия, знакомые нам всем из математики. Я использую понятие индукции для определения любого процесса, построенного на переходе от частного к общему. То есть сначала пример, и только затем теория.
Понятие дедукции в моем словаре описывает процесс, основанный на переходе от общего к частному, то есть сначала читай мануалы и знакомься с процессом, и только потом приступай к пецканью кнопочек и знакомству с трекинговой системой.

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

Лично я предпочитаю первый метод, потому что считаю, что проще объяснить человеку сразу, чем он будет тратить время, не зная где рыть (исключения - когда надо научить человека искать, и когда у меня нет времени. в таком случае на вопрос я отвечаю – ты должен найти ответ на этот вопрос сам, могу подсказать, где посмотреть). Ну действительно, не всегда ведь вся информация содержится в одном файле спецификации. Что-то вообще могло было быть выяснено в процессе переписки, да так там и остаться. Я считаю, что нужно ценить время и силы даже самых молодых сотрудников.

Мне встречались руководители, которые работали исключительно по второму методу. Такие же подходы, кстати, существуют и в повседневной работе, некоторых руководителей прямо таки раздражают вопрошающие подчиненные, и они огрызаются «как не работает? не может такого быть! ты что-то неправильно сделал. ах, ну конечно, а здесь кто галочку будет ставить? как не говорили, а кто тебе должен говорить? в релиз ноутах к патчу 5 на этот продукт о чем говорится?» и так далее, и так далее. Не знаю, чего они этим добиваются кроме кажущегося возвышения собственного «Я».

Своему первому «студенту», который уходил в другой проект, я дала совет: «Уточни у нового руководителя, как ты должен себя вести в случае возникновения у тебя вопросов? Спрашивать сразу или сначала попытаться найти ответ самостоятельно». Он поблагодарил меня за совет и через пару дней написал: «Спасибо ещё раз, новый тимлид одобрительно воспринял мой вопрос и мы с ним приняли систему «15 минут», то есть если я в течение 15 минут не могу найти ответ на свой вопрос – только тогда я спрашиваю у него или у других сотрудников».

Итак, если кто-нибудь спросит меня, каковы, на мой взгляд, основные принципы обучения, я отвечу так:
1 – всегда объяснять «студенту», почему нужно в данной ситуации делать так, а не иначе, возможно, стоит позволить ему сделать иначе, чтобы он пощупал достоинства и недостатки на практике;
2 – практика первоочередна, лучше сначала дать сделать, а потом прочитать, как можно было сделать иначе, в таком случае теория будет ложиться на практику, и студент будет видеть перед глазами то, о чем он читает;
3 – ценить время «студента», отвечать на вопросы по мере возможности, если это не противоречит «воспитательному процессу».

Я не утверждаю, что эта практика применима во всех случаях и ко всем студентам, но она помогает «студенту» почувствовать, что его ценят как специалиста.





Читать далее...