Archive | Управление проектами RSS feed for this section

Гибкие методологии или Классические подходы

Встреча организована группой профессионалов peopleVprocess при поддержке сообщества Agile.by
Формат встречи – дебаты на практических примерах, в рамках которых профессионалы поделятся опытом применения различных решений и методологий (more…)

Read full storyComments { 6 }

Бизнес в стиле Agile

Экономичный стартап (http://unova.ru/2012/01/26/9934.html) – статья на русском. О том, что надо пробовать свои идеи, проверять их право на жизнь через эксперимент. Хуже всего для бизнеса создать огромный склад с программным кодом вокруг идеи, которая никтого не цепляет. 

http://theleanstartup.com/ – сайт автора книги The Lean Startup Эрика Райса.

http://www.amazon.com/Lean-Startup-Entrepreneurs-Continuous-Innovation/dp/0307887898 – а вот здесь можно купить эту книгу на английском. Всего за $13.69 в версии Kindle. 

Read full storyComments { 0 }

Асхат Уразбаев в гостях у Рунетологии

 

Подкаст популярного интернет-шоу Рунетология с участием scrum-коуча Асхата Уразбаева. Про Scrum, внедрение его в работу команд и управление интернет-проектами.

Если вы еще не слушаете Рунетологию – срочно добавляйте в свои RSS-ленты. 😉

Read full storyComments { 0 }

Отчет по Agile Session #6

В прошлый четверг (27 мая) прошла очередная встреча Agile-сообщества. Большое спасибо БГУИР за предоставленное помещение. Зарегистрировалось на встречу более 70ти человек, пришло около 40-50 (в рядовом конференц-зале мы бы не поместились). Также выражаем благодарность Target Process за предоставленные печенюшки. Они скрасили наши разговоры после презентации.

Презентация Александра Шиляева, Wargaming.net:

Если кто-то что-то не понял из просмотренной выше презентации… ну что ж, надо было приходить на встречу, слушать и задавать вопросы автору. В итоге получилось так: 30 минут презентация и почти час ответы на вопросы. А после еще почти час общения на различные темы.

Фотографии, которые мы сделали (их, правда, немного) выложим на нашей странице в Facebook.

Мы начали думать над следующей темой нашей встречи. Планируется, что это станет тема тестирования. Паша Габриель попробует ответить на вопрос: “Нужен ли тестировщик в разработке ПО?”. У него крайне любопытное мнение на этот счет, подтвержденное практикой.

Read full storyComments { 0 }

Разница между водопадом, скрамом и лином (в картинках)

Простая визуальная разница в принципах и подходах к работе в различных методиках разработки ПО показана на картинке, которую не так давно опубликовали на сайте http://agile101.net.

Рассматриваются 4 методики разработки (не буду называть их методологиями или фреймворками):

  • Водопадный процесс разработки (Waterfall Development);
  • Итеративный водопад (Iterative Waterfall Development);
  • Скрам (Scrum Development), как разновидность Agile;
  • Лин — бережливое произвдство (Lean Development).

the-difference-between-waterfall-iterative-waterfall-scrum-and-lean

Там же можно прочитать про принципиальные различия представленных проецессов. (more…)

Read full storyComments { 0 }

Про UML, холивар и последующий холишит

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

Когда писался agile manifesto, все были утомлены фанатиками имеющихся на рынке методологий. Структурный подход и имеющиеся методики стали настолько тяжелыми, что рухнули практически везде. Но надо помнить, что изначально они были вполне работоспособными. По ним жили десятки лет, но однажды поняли, что накладные расходы на эти методологии слишком велики. Такова судьба любой хорошей методики – она обрастает деталями, диаграммами, чеклистами, чтобы разобраться во всем этом деле пишут инструкции, инструкции сводят в подборки документов, подборки перерабатывают в процессы – и оба-на! мы получили очередную мегатяжеловесную Методологию, доведенную до идиотизма детализацией и оснащенную армией фанатиков, которые борются уже не за успех проекта, а за чистоту канона – чтоб все было Как-Завещал-Великий-Ленин, и если проект от этого загнулся – тем хуже для проекта.

Похоже, то самое начинается с аджайлом. Мы недавно запускали новый проект. Проект со старта имеет довольно развесистую структуру. Представить графически эту развесистую структуру – довольно сложно. Однако для релиз плэннинга надо не только структуру представить, но и рамки очертить. Мы использовали для этого UML и Sparx Enterprise Architect. UML потому что юзкейс-диаграммы все с грехом пополам читают, Sparx – потому что удобно рисовать и все отрисованные юзкейсы можно поддерживать в синхронизации с Visual Studio Team System 2008, который используется на проекте. Соответственно затем пользуясь интеграцией Team System + Microsoft Office делаем релиз плэннинг – хоть в Excel, хоть в Project.

Подход исключительно прост, польза для проекта очевидна, удобство для команды знакомой с UML и Sparx – тоже очевидно. Рассказал про это камрадам в Питере. Что тут было! ЕСЛИ ВЫ ИСПОЛЬЗУЕТЕ UML, ЗНАЧИТ У ВАС НЕ АДЖАЙЛ! ИБО В АДЖАЙЛЕ СКАЗАНО – НИКАКОЙ ДОКУМЕНТАЦИИ! Дорогие камрады, это распространенное заблуждение. На самом деле:

  1. Если посмотреть множество диаграмм с примерами, хотя бы из книжек Бека или специальных изданий, то становится ясно – диаграммы вообще и UML-диаграммы в частности как визуальное средство коммуникаций очень ценились отцами-основателями.
  2. Аджайл не требует отсутствия документации. Если бы требовал – фотографии доски тоже были под запретом, потому что это хоть и кривая, но тоже документация. Аджайл требует минимальной и достаточной документации – и UML-диаграммы (при условии что у вас их все умеют читать) отлично эту задачу решают.
    С частным вопросом разобрались легко, но этот частный вопрос – следствие попытки превратить аджайл в некий догмат, довести его до абсолюта, и все что противоречит догмату – объявить неверным. Затем – требующим искоренения.
    Коллеги, напоминаю: изначальный посыл аджайла – ставка на умных людей и их умение думать, а не на процесс. То, что хорошо для проекта – это и должно входить в вашу методику. Все остальное – от лукавого.
Read full storyComments { 4 }

Quality assurance

Software quality assurance (SQA или просто QA) – это деятельность по оценке качества и обеспечению соответствия стандартам и процессам (хотя многие это считают синонимом тестированию).

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

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

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

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

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

  • Требования
  • Создание
  • Предупреждение проблем в будущем

(more…)

Read full storyComments { 0 }

Software People 2009. Презентация.

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

Я рассказывал о том, как мы (я в частности) пришли к принципу управления проектами по Agile и как это положительно сказалось на управлении бюджетом проектов.

Знаете, когда мы запускали работу по agile-процессу в нашем флагманском проекте я прочитал для сотрудников пару семинаров. А после одного из них попросил прислать мне их мнения. В одном из мнений говорилось, что мол “раньше я думал, что agile нужен для того, чтобы разводить клиента на деньги, но сейчас я думаю, что им он реально полезен”. Странное дело, но некоторые реально считают порочной практикой принцип agile-методики биллить часы ежемесячно даже за работу, которая может быть отвергнута в следующей итерации. При этом не понимая смысла этой гибкости.

В докладе я делал упор на тот факт, что наш заказчик всегда платит за готовый продукт. Я даже выделил это красным: готовый продукт. Эта мысль на самом деле связывает воедино отношения заказчик-разработчик в старую добруб формулу: “утром деньги – вечером стулья”. Все предельно честно.

Если вы были на конференции и не задали мне вопрос, то самое время сделать это ниже в комментариях.

Read full storyComments { 0 }

Оценка. Примеры

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

После всех теоретических рассуждений о разных способах оценки (смотри Оценка. Часть 1 и Оценка. Часть 2) давайте рассмотрим примеры оценки нескольких гипотетических проектов.

Проект «МегаХ»

Большая система, time & materials. Заказчик за Scrum, но просит изначально оценить примерные затраты и хочет иметь возможность видеть общий прогресс проекта. Хороший заказчик.

После обзорного анализа PM определяет состав команды. Так как участники проекта уже известны, то проводить оценку решено всей командой.

Для оценки всего проекта решено выбрать story points. Учитывая свой предыдущий опыт, PM рассказывает команде, почему именно story points и что они дадут (иначе команда будет считать в днях и просто называть их story point). Уф, команда за story points – тем более, что у некоторых уже есть опыт. Проводится небольшой тренинг по оценке.

(more…)

Read full storyComments { 0 }

Менеджер в agile, или как я стал тренером

Дискуссии на тему “где же менеджер в agile” ведутся давно, а чем конкретно занимается менеджер проекта продолжает интересовать людей и сейчас. Ответ же прост и одинаково формулируется и в диамате и в project management – “it depends”. И вот от чего.

(more…)

Read full storyComments { 5 }