Показаны сообщения с ярлыком scrum. Показать все сообщения
Показаны сообщения с ярлыком scrum. Показать все сообщения

среда, 12 февраля 2014 г.

Внезапно - коллеги!

Иногда, примерно раз в тысячелетие, я вспоминаю бурную админскую юность, надеваю свой волшебный плащ и волшебную шляпу и начинаю что-нибудь переустанавливать, скриптовать, настраивать и допиливать.
Что-нибудь не 1С-ное, а что-то вроде redmine на openshift развернуть и сделать так, чтобы он автоматически на cloud.mail.ru свой бэкап (базы и файлов, ессно) выкидывал, да еще и по-датам. Бывает это ну очень редко, но бывает.
А еще реже бывает так, что я связываюсь с авторами программ, чтобы спросить какого чертакак включить ту или иную фичу или просто оставить им на сайте пожелания здоровья и долголетия. Можно сказать - исключительное событие.

Решил я недавно развернуть Redmine Dashboard 2 себе в трекер. Отличный плагин, который рисует прекрасную доску по статусам трекера. Рекомендую.
Но не хватает в нем одной малости - чтобы на одной доске можно было несколько проектов крутить. Очень стал я по этому поводу сокрушаться и в трекере проекта на гитхабе, там где такие же несчастные по этому же вопросу сокрушались, отписался автору.
Автор сам там отписался что это сложновато сделать, что работы идут, и спрашивал - "Вы то как у себя используете проекты/подпроекты"?
Итак, с трудом вспомнив где у меня включается латиница (1С-ник же, хехехехе), на своем корявом английском написал:
In our team all subprojects inherit right access from toplevel project.
Also, trackers, statuses, etc. are identical from toplevel project.
The difference between the subprojects is in the list of active modules.

Знай, мол, наших.
И что вы думаете? Через пару минут комментарий:
Same way. And we use it for 1C:Enterprise too :)

Никуда теперь не выйдешь, чтоб коллегу с 1С не встретить. Ни на гитхаб, ни на хабр.
Держитесь, мы уже везде.

Для любопытствующих - пруфлинк.

суббота, 4 января 2014 г.

Эмоциональный скрам

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

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

воскресенье, 4 ноября 2012 г.

Роль в команде

Strum-master. Вам не кажется, что он слишком много говорит не по делу?

пятница, 2 ноября 2012 г.

Agile Буллшит Бинго

Распечатай эту страницу. Затем, когда ты слышишь какое-нибудь слово из таблицы — зачеркивай его. Как только пять слов по вертикали, горизонтали или диагонали оказались зачёркнуты, вставай и кричи Agile Буллшит!


P.S.: Теперь и на нашей улице праздник. Спасибо студии Сибирикс.
Я готов к следующему Agileee!

суббота, 26 мая 2012 г.

Scrumboard

Scrumboard бывает разный...

воскресенье, 30 октября 2011 г.

Новое на доске

А еще у нас на доске обновление. Ребятам понравилась идея об "аватарках" разработчиков на тикетах. Доска стала "живее":

понедельник, 25 июля 2011 г.

Эволюция доски

Сегодня нам привезли новую доску, заказанную еще итерацию назад. Она еще больше нашей второй доски, но и проектов на ней больше:

Теперь на ней есть отдельная линейка для поддержки, которая работает скорее, как мини-доска "канбан" и место под дополнительную информацию, в частности предполагается burndown.
В остальном же ничего не поменялось, кроме того, что у нас уже ВСЕ проекты ведутся через общий бэклог и почти все сотрудники отдела разработки вовлечены в процесс.

вторник, 12 июля 2011 г.

Планирование!

Наша замечательная команда на планировании:

Мизансцена: product owner за компьютером, разработчики вертят в руках колоды planing poker, доска с тикетами сгруппированными по сложности (на 0.5, 1 и 21 мало), все смотрят на вопрос в bug tracker, чтобы получше уяснить подробности и, черт-возьми, отэстимэйтить этот тикет!

воскресенье, 19 июня 2011 г.

Вперед, товарищи!

Я рассказываю о преимуществах и перспективах scrum на второй ретроспективе.

суббота, 28 мая 2011 г.

Введение в SCRUM

Алексей Кривицкий выложил неплохую презентацию "Введения в scrum". Если вы рассказываете новой команде о scrum, может пригодиться.

пятница, 20 мая 2011 г.

Вторая scrum доска

Помните, я показывал вам свою первую доску? С того времени она немого подросла, вот она:

Что изменилось? Во-первых она стала больше и исчезла колонка "Выполненно". Оказалось, что она не нужна, задачи после разработки переходят сразу в тестирование.
Во-вторых есть легенда по стикерам: желтые - обычные истории, синие - не девелоперские задачи. Например, чистое написание манов не связанное с текущим кодированием (маны-то мы и так по каждому вопросу пишем), администрирование или research. Еще есть красные, но на этом фото их нет (что хорошо). Красные - срочные, не запланированные, авральные вопросы, которые нужно быстро решать и выпускать внеочередной bug-fix.
В третьих теперь задачи на доске действительно располагаются по-приоритету (и, кстати, то, чего вы не видите это реальный приоритет, установленный настоящим product owner-ом и сложность установленная planing poker-ом).
В четвертых есть календарик на итерацию с отметками сколько дней отработано, сколько еще осталось. Это зародыш burndown. Пока мы не эстимэйтим задачи в часах и у нас еще нет разделения на user story и tasks, так что толком burndown и не построить, но все еще впереди. А пока хватает и календарика.
Ну и удобный стикер прямо на самой доске с информацией о том во сколько проходит ежедневный daily scrum. =) Теперь никто не сможет сказать, что он не знал когда и где у нас scrum. Ответ перед глазами - у доски в 9:30.

среда, 29 сентября 2010 г.

Мензоберранзан. Отчет скрам-мастера.

Начало
Среди мастеров ролевых игр, так же как и среди разработчиков, бывает так, что появляются проблемы коммуникации внутри команды. Но, если у разработчиков есть тот самый волшебный scrum, то для мастерских команд пока нет каких-то универсальных рецептов-фреймверков.
И вот, совсем недавно благодаря уважаемой Юлии Владимировне, у меня появилась возможность попробовать одну из техник методологии scrum на ролевом проекте Мензоберранзан – технику «daily scrum» или, как ее еще называют «мастерские планерки».

Адаптация
Для начала была сделана адаптация ко временным рамкам. Если у разработчиков итерация длится 2-3 недели, то тут срок всего проекта 4-5 дней. Логически было удобно представить, что один день это одна итерация. В итерацию изначально мы решили включить 4 планерки (последняя совмещенная с ретроспективой). Так же пришлось немного изменить последний из трех вопросов («Что мешает?») на «Хоз.вопросы». Это было нужно, так как мастера по-сути высший «решающий орган» на полигоне и если откинуть ответ «мешают игроки», то останется только влияние окружающей среды, погода и хоз.часть.
Так же отдельно было оговорено проведение «медленной» части планерки, что для девелоперов, как правило, очевидно.
Подробности можно посмотреть в полном scrum-манифесте для этого проекта, который был опубликован в самом начале, как основной документ.

Практика
Для начала несколько слов о технике.

Оказалось, что четыре планерки в день это слишком много, так как игроки постоянно нуждаются в присутствии мастеров и начинают беспокоиться и нервничать, когда слышат, что «мастера на планерке». Начиная со второго дня, мы сократили их количество до трех (утро-обед-вечер). Это было хорошее решение для игроков и приемлемое для мастеров.
Возможно, это связано со спецификой игры и с тем, что в данном игровом мире слишком многое завязано на мастеров. Во всяком случае, я бы попробовал еще раз вернуться к 4-м в день в более «независимом» игровом мире.

Второе, что пришлось отменить, это обязательный стэндап. Действительно, очень сложно целый день мотаясь на своих двоих по полигону, потом стоять на вечерней планерке. На самом полигоне я не стал настаивать на строгом соблюдении стэндапа, но к моему приятнейшему удивлению мастера сами старались проводить планерки стоя, только на вечерних некоторые сидели. Мне кажется, что это тот случай, когда команда самоорганизовалась вокруг хорошего и прозрачного принципа, понятного всем – стэндап не превращается в «посиделки».

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

Баги
Одной из самых серьезных проблем в отношении планерок было то, что мастера люди, а не роботы. :)

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

2. Некоторые мастера недостаточно ответственно относились к своей очереди выступления и в свой рассказ включали только общие фразы вроде «делал все то же самое, буду делать это же». Зато вставляли множество дополнений в рассказы других мастеров с комментарием «о, я забыл что…»
Это тоже пагубно отражалось на времени, кроме того имело еще один серьезный побочный эффект. Тот, кто чаще всего говорил «о, я забыл что» посреди чужого рассказа в итоге сам не слышал остальных, так как был сосредоточен не на том, что говорит другой, а на том, что ему нужно добавить.

3. И третье это, наверное, не бага мастеров, но тоже важный момент. Очень мало внимания уделялось второму вопросу «Что будет?» (или «Что буду делать?»). Понятно, что игра развивается непредсказуемо и у многих, например, у мастера боевки, не может быть особых планов, если неизвестно будут ли вообще боевые эпизоды. Поэтому этот пункт планерки нужно обсудить. Если он не нужен, возможно, исключим его или преобразуем в нечто полезное.

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

P.S.:
С момента написания этого отчета уже прошло достаточно времени, мы успели обсудить недостатки подхода (и как бы провести общую ретроспективу по работе техники) и выдвинуть несколько хороших идей, которые войдут в скрам-манифест на следующий проект.

Я обязательно напишу о том, что из этого получится, следите за обновлениями.

среда, 30 июня 2010 г.

Я вернулся!

И вот, после небольшого перерыва я снова с вами!

Поделюсь вкратце тем, что было. Во-первых я до-сих пор под впечатлением от AgileBaseCamp. Один из самых прекрасных докладчиков (из тех, на которых я попал, разумеется) это Александр Орлов, рулевой проекта Happy-PM и вообще мегамоск.

Вот он, в оранжевой футболке:



На доклад Тимофея Евграшина я не пошел специально, потому что предполагал попасть на его замечательный мастер-класс и перекинувшись парой слов "в кулуарах" утвердился в своем решении. Забегая вперед хочу сказать, что этот мастер-класс стал логическим завершением AgileBaseCamp.
Уже есть фотоотчет с мастер-класса, вот некоторые фото:

Мой шеф включается в работу:

Играем в спринт и планирование. Звучат страшные слова velocity и capacity:

Тим получил кружку QAClub:

И общее фото:




И еще одно фото, которого нет в альбоме. Оказалось, что мы возвращаемся с Тимофеем одним поездом.
Вокзал:

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

пятница, 4 июня 2010 г.

Горы и магометы

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

P.S.: В любом случае, даже если мы придем к magile это будет существенное упорядочивание процесса.

четверг, 22 апреля 2010 г.

Microsoft Visual Studio 2010 и TFS 2010

В Киеве прошел запуск Visual Studio 2010. Ну, что можно сказать... За что я люблю Microsoft-овские сборища, так это за то, что там хорошо кормят и кофе бесплатно. ;-)

Это, как вы понимаете, шутка. А теперь серьезно.
Лично я был на серии докладов о VS и TFS (большой зал) и меня очень удивило, насколько сама Microsoft и ее продукты agile-ready. Надеюсь, они скоро выложат видео-запись, а пока скажу, что в самом начале серии докладов они сказали: "Сегодня не будет показано ни одного слайда. Мы прямо перед вами "в живую" отработаем один спринт (второй в проекте, если быть точным)". Обещание было сдержано - слайдов не было. Они действительно отработали одну scrum-итерацию распределив между собой роли (заказчик, скрам-мастер, pm, архитектор, разработчик, qa), полноценно от UserStory's до тестирования, демо и ретроспективы. Конечно, было много "домашних заготовок", вся инфраструктура уже была развернута и задачи были не сложными, но все же это было интересно и очень удивительно для меня. Да, глюки тоже были. ;-)

О самой VS. Что можно сказать. Это монстр. Нет. Это МОНСТР! Оно, как вы догадываетесь, интегрируется со всем чем можно и полноценно использует развернутую ms-инфраструктуру. О разных новых фичах можно рассказывать долго, но лучше вы почитайте обзоры, а я расскажу о том, что мне особенно понравилось.
Первое - это архитектурный контроль. Архитектор может построить некую диаграмму объектов проекта, где в качестве объектов могут выступать классы, модули, библиотеки и пр. И установить между ними связи. При вызове функции архитектурного контроля VS проверяет насколько существующий код соответствует диаграмме. Например, если у вас есть UI, который обращается к классу DBIntreface, который в свою очередь должен работать с БД, то построив диаграмму связей вы сразу же можете обнаружить где разработчик напрямую из UI дергает БД в обход DBIntreface, и указать ему на ошибку.
Второе, что очень запомнилось это "Центр тестирования". Интересный продукт, позволяющий проводить автоматическое и ручное тестирование приложений. Удобные инструменты, плюс опять-таки интеграция. Тест-кейсы с привязкой к юерз-сториз и все-такое.

Это была положительная сторона. О слабых моментах и негативе писать не буду, потому что, те, кто реально будет работать с Visual Studio 2010 найдут их сами, а общие о том, что "продукты MS слишком "толстые", что "нормально интегрируются только с другими продуктами MS" и т.д. и так все знают.

Конечно, доклады от Microsoft теперь все меньше похожи на доклады для технических специалистов, а скорее напоминают театрализованное представление, но в целом от продукта впечатление приятное, а главное, что я теперь как-то глубже и нагляднее представляю себе scrum. Вот уж чего не ожидал! =)