Agile в неравенствах

Автор: Александр Якима (www.enter-agile.com)

Существуют два важных неравентсва, которые раскрывают суть гибкой разработки (записываемые для простоты одной строкой):

трудозатраты != результаты != ценность

Выглядит очень просто. Попробуем посмотреть, что стоит за этой формулой... по частям:

1. трудозатраты != результаты. Это неравенство в первую очередь относится к команде разработчиков. Тем более оно как раз особо важно для заказной разработки, или даже лучше будет сказать: контекст этого неравенства является в области контроля команды разработчиков, в отличие от неравентсва №2 (см. ниже). Это неравенство оипсывает правильную психологию гибкой команды, для которой важен только результат - они его регулярно достигают посредством инкрементов итераций и соответсвенно с практической позиции знают, что методы и трудозатраты, необходимые для достижения результата, чаще всего оказываются совсем не такими как казалось по-началу.
Несколько типичных иллюстраций:

Технический аванс vs. технический долг. Есть у многих разработчиков такая слабость: при имплементации фичи дойдя до определенного слоя системы начать "закладываться" под другие гипотетические фичи: "раз уж я здесь, то сделаю больше... а то что это за слой такой - всего два класса...". Эффективным будет на самом деле оставить минимальное минимальным, а с точки зрения того, насколько нужно "закладываться" под кое-какую общность - исходить из простого правила: всегда лучше сделать, получив на выходе результат, имеющий ценность для конечного пользователя (читай - работающий продукт) и таким образом взять технический долг, который потом "отдается" в форме рефакторинга, чем брать технический аванс и не знать, что с ним потом делать по отношению к пользователю. Так вот, реализованные фичи - это уже результат независимо от того, сколько трудозатрат на нее потрачено, а слой системы - это слой системы и не более, его пользователь не то что применить не сможет, но даже объяснить ему не сможете, что это такое. Итак, сделав слой "наугад" команда а) на 90% рискует ошибиться и б) лишает себя дополнительных опций в принятии технических решений в будущем - а это даже хуже. Итак, добиваемся результата любой ценой, оставляя, возможно, за собой технический долг, который в последствии отдаем в форме рефакторинга.

Перфекционизм. Почему-то часто принято считать, что перфекционизм как-то положительно связан с профессионализмом. Нет, есть конечно несколько форм положительного проявления перфекционизма, например: например, в постоянной поддержке бэклога, или в том, чтобы не давать дефектам переходить в следующую итерацию и т. д. Но что на самом деле обычно является предметом усердствований перфекциониста? Именно так: как писать юнит-тесты, как писать код, что выносить, а что нет в конфигурационные файлы и т. д. У всего этого есть одно общее свойство - акцент на низкоприоритетных вещах. Вроде бы и лишних "движений" по слоям не делается, как в предыдущем случае, вроде бы появился только нужный код, но увы, на его "полировку" уходит уйма усилий в то время, когда нужно всего лишь грубо отшлифовать. Тут нельзя не вспомнить советскую 34-ку, грубую, везде похабно подвареную, но достаточно надежную и, самое главное - дешевую в производстве, по сравнению со сверхкачественными Тиграми, которые требовали много дорогих как сырьевых, так и человеческих ресурсов. Советский танк тогда выиграл войну своей легкостью в производстве и поддержке, это прекрасный исторический пример, свидетельствующий о здоровом расчете: место танка - на поле боя, а не на автошоу.

2. результаты != ценность. Допустим теперь для простоты, что мы имеем дело с идеальной командой разработчиков, всецело понимающей и на практике руководствующейся неравнеством №1. И все же, несмотря на нацеленность на результат, результат этот может не нести должной ценности конечному пользователю - и действительно существует немало примеров прекрасной реализации релизов продукта, никому не нужного, как оказывается в последствии. "Это не проблема разработчиков", - скажут разработчики и будут почти правы, так как этот пункт почти полностью относится к обязанностям продакт-оунера. Это неравенство какраз выражает ту простую мысль, что правильное задание приоритетов - кардинально сложная задача. Если неравенство №1 "срабатывает" на уровне итерации, то неравенство №2 - это уровень релиза, так как нет иного эффективного способа эффективно валидировать свои гипотезы о приоритности фич, как посредством частых релизов и активного сбора фидбеков от пользователей. Тут и становится понятным использованное нами наречие "почти": команда должна научиться релизить часто. Часто - понятие относительное, но если разработка производится командой из 5 - 30 человек, полностью покрывающих разработку системы, то 6-8 недель - абсолютно достижимый и даже весьма рекомендуемый таймбокс для релиза.

Наконец, отмечу, что эти неравенства следует учитывать при построении системы KPI для сотрудников, измеряя их полезность не просиженными часами и выпитыми чашками кофе, а завершенными задачами, и даже больше - бизнес-показателями конечного продукта.

No comments:

Post a Comment

 
Powered by Blogger