Заметки о разработке с использованием Scrum
#1
Отправлено 12 апреля 2006 - 14:48
Автор: Вячеслав Дукальский
В отличие от традиционных подходов к управлению разработкой ПО, включающие в себя детальные планы, диаграммы, расписания, тестовые спецификации и прочие документы, которые с избытком научились производить менеджеры проектов еще до того, как проект начался, Scrum предлагает вести проект своим оптимальным курсом, раскрывая все технические подробности уже в ходе этого пути.
Scrum предоставляет эмпирический подход к разработке ПО. Этот процесс быстр, адаптивен, умеет самонастриваться и отличен от последовательного (водопадного) подхода. Scrum основан на повторяющихся циклах, это делает его более гибким и предсказуемым. В основе лежат короткие ежедневные встречи — Scrum и циклические 30-дневные встречи, называемые Sprint. Во время ежедневного Scrum'a каждому члену команды задаются только 3 вопроса:
1. Что было сделано с последнего Scrum'a?
2. Что вы будите делать между этой и следующий встречей Scrum?
3. Что мешает вам выполнять работу?
---------------------------------
Другие материалы раздела <Менеджмент>
#2
Отправлено 27 апреля 2006 - 02:46
Автор считает, что планирование, да и документирование вообще придумали менеджеры (а менеджмент, видимо, полагается изначальным злом). Как там насчет сравнения с другими видами индустрий? Пусть-ка автор найдет пример полного цикла проектирования и производства, скажем, авиалайнера или моста методом вроде рекламируемого Scrum, то есть «куда кривая коза вывезет». Сразу делается очевидно, что мост эдак можно создавать только на уровне пары бревен, кинутых через ручей.
#3
Отправлено 27 апреля 2006 - 03:54
Просто отмечу, что доля смысла есть, но уж никак не замена планам, требованиям и т.п.
Возможно, как часть процесса, имеет смысл.
Подобный Scrum - это у нас часть пятничного собрания :)
#4
Отправлено 27 апреля 2006 - 07:35
Не стану резко выражаться
Просто отмечу, что доля смысла есть, но уж никак не замена планам, требованиям и т.п.
Возможно, как часть процесса, имеет смысл.
Подобный Scrum - это у нас часть пятничного собрания :)
На мой взгляд, не очень эффективно устраивать такие митинги в пятницу по ряду причин:
1. К понедельнику впечатления потускнеют, часть минорных решений, не зафиксированная документально, может попросту остаться за бортом;
2. В пятницу сложно ожидать от участников полноценной фокусировки на рабочем процессе;
3. Если принимаются решения о проведении мероприятий, направленных на вытаскивание проекта из различных нелитературных мест, то реализовывать эти мероприятия эффективнее немедленно, на кураже, а не дожидаясь понедельника.
Думаю, коллеги менеджеры смогут найти еще немало аргументов.
Поэтому многие проводят такие митинги в понедельник. Но наиболее эффективно, по моему мнению, проводить их в середине недели, во вторник или среду.
#5
Отправлено 27 апреля 2006 - 08:40
На мой взгляд, не очень эффективно устраивать такие митинги в пятницу по ряду причин:
1. К понедельнику впечатления потускнеют, часть минорных решений, не зафиксированная документально, может попросту остаться за бортом;
Ну, во-первых, митинги устраиваются не обязательно каждую пятницу.
Во-вторых, всё таки все обсуждаемые вопросы фиксируются, и именно документально.
2. В пятницу сложно ожидать от участников полноценной фокусировки на рабочем процессе;
Это уж извините, у кого как :) В конце рабочего дня, когда думать уже о завтрашней работе не нужно, то можно свободно пообщаться и с чистой совестью идти домой. Ну и слово "пятница" здесь, конечно, весьма условно. Смысл то не в этом был.
#6
Отправлено 27 апреля 2006 - 09:25
Ну, во-первых, митинги устраиваются не обязательно каждую пятницу.На мой взгляд, не очень эффективно устраивать такие митинги в пятницу по ряду причин:
1. К понедельнику впечатления потускнеют, часть минорных решений, не зафиксированная документально, может попросту остаться за бортом;
Во-вторых, всё таки все обсуждаемые вопросы фиксируются, и именно документально.
Стенографируете? Я говорил о минорных решениях, т.е. решениях, которые нет смысла фиксировать, но которые в понедельник придется вспоминать.
Простите, как это не нужно думать о работе? А о чем тогда общение?2. В пятницу сложно ожидать от участников полноценной фокусировки на рабочем процессе;
Это уж извините, у кого как :) В конце рабочего дня, когда думать уже о завтрашней работе не нужно, то можно свободно пообщаться и с чистой совестью идти домой.
#7
Отправлено 27 апреля 2006 - 09:39
Похвально Ваше стремление к написанию статей. В моем представлении, человек пишущий статьи - это человек увлеченный (как минимум). При всех равных, при приеме на работу я бы отдал предпочтение тому, кто пишет.
Но Вам нужно учитывать критику. После Вашей предыдущей статьи было много замечаний, и эта, похоже, тоже не минует их. Самый верный способ написать хорошую статью, это обсудить ее со своими коллегами или другими специалистами. Предлагаю Вам попробовать этот способ.
В отношении же самой методологии Scrum нужно понимать главное. В чем, собственно, она отличается от процессной модели? В чем ее сильные и слабые стороны? Проведение ежедневных 5-15 минутных митингов - это не есть методология. Это всего лишь элемент организации работ.
Меня давно интересует эта тема, но я, хоть убей, пока так и не понял, что же такое Agile в тестировании! (Agile здесь как собирательный образ всех не процессных методологий.) В программировании - понимаю и даже могу себе это представить, но в тестировании - не могу.
Как можно тестировать не имея четких критериев на входе? Какие могут быть Agile приемы при контроле параметров заготовки под карданный вал (к примеру)? Если у вас нет на входе четко сформулированных критериев, что чему должно соответствовать, то что вы будете проверять?!
Как проверять - это другой вопрос и его можно обсуждать. Но если в проекте нет сформулированных функциональных требований к системе (а это, например, одно из достоинство методологии ХР), то что проверять?
На мой взгляд, в тестировании Agile методологии не приемлемы. Отдельные приемы - да. Но так, что бы можно было сказать, что вместо RUP (MSF или другой процессной модели) мы применяем тестирование по XP (именно в тестировании, а не в разработке), пока что представить себе не могу.
#8
Отправлено 27 апреля 2006 - 11:55
Скажем так - есть твоя работа по плану - которая касается именно тебя. И пока она не сделана, то переключаться на обсуждение задач в целом, очень не хочется.Простите, как это не нужно думать о работе? А о чем тогда общение?
А есть видение ситуации в целом. И там обсуждается, к примеру, кто что сделал, как дальше жить будем и т.п.
Так вот, в пятницу под конец рабочего дня очень полезно отключаться от собственных дел и переходить на обсуждение дел коллективных. К тому же за неделю скапливается много вопросов и в том числе таких
Согласен, что нужно обсуждать моменты, которые всем или кому-то непонятны....Но что делать, если задача слишком сложна и не до конца всеми понята?
И люди с удовольствием делятся тем, что у кого "наболело". В зависимости от этого в дальнейшем корректируем планы...
Вам правильно написали, что
Я, например, статей не пишу. Не получается у меня. Но писать ради того, чтобы просто писать тоже не буду.Похвально Ваше стремление к написанию статей. В моем представлении, человек пишущий статьи - это человек увлеченный (как минимум). При всех равных, при приеме на работу я бы отдал предпочтение тому, кто пишет.
Не хочу вас оскорблять, но когда человек пишет, что "вот моя технология - это то что нужно, вместо планирования и составления требований" (почему то я воспринял это так и мое мнение в чем-то совпало с Mir -ом), то у меня это вызывает определённую долю здравого скептицизма...
А вот то, что идея корректировки проекта могла бы быть вашим Scrum-ом, как дополнение к планированию - я приветствую. Ничего личного, спасибо за статью :)
#9
Отправлено 28 апреля 2006 - 14:51
И пока у нас будут в девелоперских организациях продвигаться вещи типа Scrum или XP, производимое ПО будет все хуже и хуже. Это ведь потачки ленивому разуму: эх-ма, поехали, куда-нибудь да приедем, кривая вывезет. Это, в общем, краткое содержание подобных облегченных методологий.
расскажите, пожалуйста, о проектах в которых Вы участвовали.
В какой роли, что делали.
Какие процессы использовались.
#10
Отправлено 02 мая 2006 - 09:20
Желаете фаллосометрией заняться? Вместо технических аспектов будем обсуждать опыт друг друга?расскажите, пожалуйста, о проектах в которых Вы участвовали.И пока у нас будут в девелоперских организациях продвигаться вещи типа Scrum или XP, производимое ПО будет все хуже и хуже. Это ведь потачки ленивому разуму: эх-ма, поехали, куда-нибудь да приедем, кривая вывезет. Это, в общем, краткое содержание подобных облегченных методологий.
В какой роли, что делали.
Какие процессы использовались.
Впрочем, извольте. В IT-индустрии с 1987 г. Проекты были разные, в основном для нефтегазодобывающий компаний, последний проект для одного из дочерних предприятия Газпрома уже идет 5 лет. Роли были и есть разные: кодер, проектироващик, аналитик, DB architect. В плане методологий использовалось тоже много чего, но в последние годы RUP.
Плюс преподавание софтверных дисциплин в ВУЗе.
И что?
#11
Отправлено 02 мая 2006 - 13:24
Долго терпел и не выдержал :)
Вот используете вы RUP... Ни один здравомыслящий опытный человек не скажет, что он использует его на 100%. Используются определенные методики, но не все. Так как даже авторы RUP признают, что не все в их методологии так гладко.
Это - с одной стороны. А с другой:
Кто вам сказал, что в XP, Scrum и прочих "гибких" методологиях не используют планирование, тестирование и т.д.? Используют, еще как. Все "гибкие" методологии основаны на определенном конечном наборе методик, известных давным-давно, ничего нового они не придумали, просто взяли лучшее из той же RUP, а про остальное честно сказали: "На хер!".
Не забывайте, что гибкие методики накладывают жесткие ограничения на размер команды. И дело тут, как мне кажется, не в том, что методология для больших команд не работает. Просто нельзя собрать многочисленную команду настолько опытных разработчиков. А с неопытными в "гибкие" методологии играть бессмысленно - загнешься на 100%.
Жесткость правил, накладываемых гибкими методологиями значительно выше, чем в формальных. Но правил этих меньше.
В заключение: никогда не работал в больших коллективах. Максимум, что-то около 25 человек, включая дизайнеров, тестеров и т.д. Те методики, которые предлагают адепты гибких методологий - рулят. Они действительно помогают создавать продукт быстрей и качественней. Это - мой опыт.
Правда, чистота эксперимента нарушена - все же большинство людей с опытом и без всяких методологий начинают быстрей свою работу выполнять, и иногда даже лучше :)
#12
Отправлено 02 мая 2006 - 13:39
Правильно говорите, уважаемый. Вот только -- где это в статье отражено? Не сказано про это в статье! Именно этим и недоволен народ, указывая, что статья носит спекулятивный характер.Кто вам сказал, что в XP, Scrum и прочих "гибких" методологиях не используют планирование, тестирование и т.д.? Используют, еще как. Все "гибкие" методологии основаны на определенном конечном наборе методик, известных давным-давно, ничего нового они не придумали, просто взяли лучшее из той же RUP, а про остальное честно сказали: "На хер!".
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#13
Отправлено 02 мая 2006 - 15:27
Желаете фаллосометрией заняться? Вместо технических аспектов будем обсуждать опыт друг друга?
Спокойнее, пожалуйста. Вас пока что никто не пытался обидеть.
Желал понять что это было - демагогически высказанная личная позиция, "не использовал, но осуждаю", или это вьюнош резвый книжку прочитал.
По поводу статьи.
не ахти какие вариации на тему http://www.controlchaos.com/about/ потому и мало интересны мне лично. Есть более интересные источники информации, например этот.
По поводу Вашей реакции ("пока у нас будут в девелоперских организациях продвигаться вещи типа Scrum или XP, производимое ПО будет все хуже и хуже. Это ведь потачки ленивому разуму: эх-ма, поехали, куда-нибудь да приедем, кривая вывезет."). Демагогический выкрик, вроде "не использовал, но осуждаю", относящийся не с статье, но к любой light-weight, agile methodology.
Без примеров из личного опыта не воспринимаю иначе.
Мой опыт ближе к тому, что prof описал. С вариациями, конечно.
Про RUP. Agile & RUP не есть взаимосключающие вещи, см. например http://www-128.ibm.c...rebs/index.html
Кстати, и в Microsoft нв некоторых проектах SCRUM & XP используют ( http://weblogs.asp.n.../04/396965.aspx ).
Конечно всему свое место. См. линк [1]
По поводу тестирования в agile projects.
Читайте про 'context-driven testing' & around.
[1] http://www.io.com/~w...our_schools.pdf
[2] http://www.testinged...gRevolution.pdf
[3] http://groups.yahoo..../agile-testing/
[4] http://groups.yahoo....ftware-testing/
#14
Отправлено 02 мая 2006 - 16:23
Правильно говорите, уважаемый. Вот только -- где это в статье отражено? Не сказано про это в статье! Именно этим и недоволен народ, указывая, что статья носит спекулятивный характер.
Статья - да, статья просто никакая. Не хочу никого обижать, но что написано - то и оцениваю.
#15
Отправлено 03 мая 2006 - 06:08
Если хотите, мой пост был ответной реакцией на характер статьи, с "перекосом" в другую сторону.
Если говоритьо моем действительном отношении к подходам вроде SCRUM, XP, я считаю их скорее не промышленными методологиями разработки ПО, а скорее набором best practises, фактически -- полезных советов. С какими-то согласен, с какими-то нет. Например, я практиковал pair programming задолго до появления XP, и нахожу это практику весьма полезной и незаслуженно мало применяемой. А вот принцип "Simple Design" заставляет меня хвататься за револьвер, так как противоречит всему опыту разработки ПО за полвека (и моему личному) и здравому смыслу. Это именно то, что я называю потачкой ленивому разуму: не заглядывай вперед, живи сегодняшним днем, а там рефакторинг (кривая коза) авось да вывезет.
#16
Отправлено 09 июня 2006 - 15:00
В каждой методологии можно найти свои плюсы и минусы, но agile-методологии это и есть, как вы сказали «промышленные»Согласен, мои высказывания носят резкий и довольно поверхностный характер. Я не хуже вас, гг. dlg99 и prof, понимаю, что и промышленные, и agile- методологии имеют свои плюсы и минусы, свои области применимости.
Это можно расписать хорошо и подробно на несколько страниц. Но сделать это хоть в минимально корректной степени должен был автор статьи. Вместо объективного, сугубо технического подхода он предпочел делать не вполне корректные рекламные заявления, относительно слабо связанные с реальностью.
К сожалению реальность сложнее, чем это кажется на первый взгляд. Если заниматься одним и тем же много лет, то можно начать считать себя гуру, который все знает и которому ничего нового не нужно и который потихоньку начинает прибывать где-то уже в другой, своей собственной реальности. Скажите, вы слышали когда-нибудь до этого о Scrum? Теперь хотя бы слышали… Можно я немного порекламирую Scrum? Вам как человеку науки важны технические детали … действительно этого там нет. Признайтесь, вы считаете что разработка ПО это чисто техническая проблема?
Scrum это не набор полезных советов, это и есть методология, там все описано, от планирования ролей до баг-репортинга. Не пожалейте несколько десятков долларов и закажите книжку Кена Швабера, указную в статье.Если хотите, мой пост был ответной реакцией на характер статьи, с "перекосом" в другую сторону.
Если говоритьо моем действительном отношении к подходам вроде SCRUM, XP, я считаю их скорее не промышленными методологиями разработки ПО, а скорее набором best practises, фактически -- полезных советов. С какими-то согласен, с какими-то нет. Например, я практиковал pair programming задолго до появления XP, и нахожу это практику весьма полезной и незаслуженно мало применяемой. А вот принцип "Simple Design" заставляет меня хвататься за револьвер, так как противоречит всему опыту разработки ПО за полвека (и моему личному) и здравому смыслу. Это именно то, что я называю потачкой ленивому разуму: не заглядывай вперед, живи сегодняшним днем, а там рефакторинг (кривая коза) авось да вывезет.
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных