В этом посте я отступлю от темы тестирования и коснусь управления разработкой, a именно, популярной и многими любимой технологии SCRUM. Эта технология оценки трудоемкости и управления задачами обладает многими преимуществами перед классическим водопадом. Она проста и понятна. За исключением одного момента – Story point. Эти условные “баллы сложности” вначале всегда вызывают вопросы – что же это?
Классики советуют не думать о них в понятиях времени, тем не менее, в большинстве случаев использования, поинты приводятся к часам, ну или дням, кому как удобнее. Думать о storypoint как о строчках кода - тоже неправильно. Количество строк кода очень сложно определить заранее и зачастую это не показатель.
Когда я рассказывал о scrum своим коллегам, я получил вопрос – каков же физический смысл в этих оценках?
Физический смысл донельзя прост – это деньги. Смотрите, что получается…
Давайте для простоты приравняем очко сложности ста рублям. Тогда задачи будут оцениваться в деньгах. Процедура оценки задач станет торговлей – руководитель проекта выставляет задачу на торги, эту задачу один программист готов выполнить за 1000 рублей, другой за 750. Остальная практика оценки задач не меняется, не буду описывать – все по скраму. Мы избавляемся от преобразований баллов в человеко-часы, это больше не нужно. Программисту сразу понятно, сколько он заработает и сколько он теряет занимаясь прокастинацией. Сроки отходят на второй план, они будут минимальны.
Думать о сложности в понятиях денег проще и руководителю и программисту. Руководитель имеет перед собой общий бюджет проекта, как правило согласованный заранее, его задача не выйти за эти пределы. Думая о проекте в абстрактных единицах легко забыть о реальности, а тут – живые деньги, которые получит программист за выполнение определенной задачи. Понятия “хороший” программист и “плохой” программист обретают свой физический смысл – хороший выполняет задачи за более короткое время и, о чудо!, получает больше. Причем сразу, не дожидаясь признания коллег и начальства, зачастую субъективного. Программист волен в определении сроков выполнения той или иной задачи – ему все равно заплатят по сложности. Мотивация налицо – быстрее делаешь – больше получаешь. Вопрос качества пока отложим, тестировщики должны получать зарплату по другому, но очевидно, нельзя засчитывать задачу выполненной без ее принятия ответственным лицом. Это относится не только к скраму. Программист волен в распределении времени в пределах задачи, сколько потратить на код а сколько на изучение проблемы. Смысл в графике рабочего времени снижается до минимума, достаточно определить время общих собраний или вовсе обойтись смс рассылкой.
Я надеюсь, что такой взгляд на SCRUM вызовет обсуждение, жду ваши комментарии
Сообщения
6 комментариев:
Да, уже не первый раз такие рассуждения читаю, причём даже не обязательно насчёт scrum. И я однозначно против. Такая система разобщает коллектив, команду. Каждый становиться индивидуалистом, думает только о том, чтобы выбить себе задачу по проще и по дешевле. Это в корне противоречит как scrumn'у, так и вовсе agile'у. В гибких методологиях команда ставится приоритетным. Некоторые моменты, которые упущены.
1. Качество это не только отсутствие багов, которое проверяет сторонняя команда QA, но и качество кода, его читаемость. Этот код должен поддерживаться дальше, а не быть наспех собранным набором костылей, только чтобы побыстрее закончить эту задачу.
2. Никакого knowledge transfer, каждый думает как ему сделать свою задачу и не станет тратить своё время, чтобы объяснять другому прогреммисту что-то, путь даже это и код, который он написал неделю назад.
3. deadline. О да без него никуда. Как этот вопрос решать, т.е. программист должен выдать не только цену, но и срок, когда это готово будет.
4. О, да, что делать со злостными нарушителями, кто выполняет задачу не в срок, или с кучей багов? Понятно, что баги он должен исправить, так сказать, бесплатно. Но после того как он их исправит, снова надо проводить регрессионное тестирование... Да и о тестировании. У нас на проекте, программисты в нём активно участвуют:
a) модульные тесты. Многие программисты даже сейчас не хотят их писать, так как это отнимает время. Проще дождаться репорта от QA. И это совершенно не правильная позиция, но в вашей системе она будет популярна.
б) автоматические интеграционные тесты. Тут уж тем более никаким дрыном не заставишь программистов.
Конечно, это может быть включено как часть описания задачи, например 100% покрытие кода модульными тестами. Но это сакс, потому что я знаю 100500 способов как добиться 100% покрытия, приэтом ничего не протестировав, но потратив минимум времени.
Вообщем то, что вы описали, это odesk, толпа индусских freelancer'ов с постоянно депингующими рейтами, а не команда, а тем более не scrum.
Это в общем о методике.
А в целом, зря вы ещё к ней и Scrum приплели, так как Scrum в частности и agile в общем, пропагандирует тесную командную работу.
Советую прочитать
Scrum и XP: Заметки с передовой (http://www.infoq.com/minibooks/scrum-xp-from-the-trenches)
Story points это время, они нужны, чтобы решить, что влезет в этот спринт, а что нет и они не часы, потому что после каждого спринта, коэффициент преобразования story points в часы может меняться, в зависимости от того как завершила команда этот спринт. Оценка работ в часах нужна, и в этом совершенно согласен с мистером Спольски (http://www.joelonsoftware.com/items/2007/10/26.html)
А касательно оплаты, меня более чем устраивает стандартная схема с фиксированной з.п. плюс премия, если было сделано что-то действительно очень хорошее, и конечно постоянные пересмотры з.п.
А вот, нашёл вашу мысль, только как мне кажется более полно описанную и отталкивающуюся не от притянутого за уши scrum
Программистский синхрофазотрон:аукциона задач
Ах чёрт, конечно же забыл написать про архитектуру приложения. Крутилось в голове, а потом забыл. Кто будет проектировать архитектуру, взаимодействие компонент..
Такой путь покатит только с маленькими или очень обособленными задачи или багами. Но для начала надо сделать такое разбиение...
Вообщем совершенно не нравиться эта система, хоть я и програмист и хочу получать адекватную оплату труда, но по мне такая схема исключительно для freelancer'ов и консультантов. Для решения обособленных задач. Но всю команду на такие рельсы переводить это ахтунг.
Такой подход применим для консалтеров, легко понять сколько денег человек заработал для компании, но проектную команду он развалит, каждый сам за себя, зачем помогать другому, если можно заработать больше денег самому?
Так же, скорее всего снизится качество продукта, будут возникать частые конфликты между разработчиками и тестировщиками и т.д.
На мой взгляд, результат будет абсолютно обратный.
За ссылку на синхрофазотрон - спасибо, тут только остается процитировать строки из "Воскресиния"
"И мне казалось что без моих
Мир не сможет прожить и дня
Оказалось в мире полно людей
И все умней меня" :)
Тем не менее я рад, что не одинок в таком взгляде на вещи. Я думаю, что противоречие между сдельной оплатой труда и командной работой можно устранить, смутное такое ощущение, пока не могу обосновать.
Odesk защищать не буду, но замечу что там очень много наших соотечественников, пишущих отличный код.
SCRUM здесь не притянут "за уши", а как раз взят как методика оценки задач.
> Тем не менее я рад, что не одинок в таком взгляде на вещи. Я думаю, что противоречие между сдельной оплатой труда и командной работой можно устранить, смутное такое ощущение, пока не могу обосновать.
Да, такое мнение часто встречается. Но насколько я вижу, это применимо к опытным программистам, которые упираются в потолок зарплат.
> Odesk защищать не буду, но замечу что там очень много наших соотечественников, пишущих отличный код.
С этим совершенно согласен, и как я написал выше, если мы говорим о нескольких отличных профессионалах, то да, ваш подход может сработать, и odesk я привёл потому, что он отражает действительность, профессионалов мало и многие из них не захотят браться за копеечные задания, вот и получим, что получим.
> SCRUM здесь не притянут "за уши", а как раз взят как методика оценки задач.
Да наверно погорячился, так как обычно в scrum оценивают время, но если подумать, время это тоже деньги с каким-то коэффициентом :)
Отправить комментарий