Мне все чаще кажется, что Agile-ориентированная команда должна вести блог. Нормальный, полноценный блог о разработке своего проекта. Несмотря на то, что основная идея Agile-религии заключается в человеческих коммуникациях вместо формализованных отношений, необходимость в документах все же возникает. Ну хорошо, не буду использовать слово "документ", потому что оно автоматически попахивает различными смыслами, которые могут в него вкладываться в тех или иных контекстах - пусть лучше это будут просто письменно зафиксированные знания, накопленные в процессе этих самых коммуникаций.
Мы пробовали уже много разных способов фиксации требований и обсуждений.
1. Самый экстремальный подход - только устное общение, либо общение по различным мессенджерам - очень хорошо действует в начале разработки, когда у проекта еще нет истории, нет наследованного кода, и поэтому все решения принимаются легко и единогласно. Бизнес приблизительно знает, чего он хочет. Мы приблизительно знаем, как мы это будем делать - вот и делаем наиболее простым и понятным способом. Со временем, когда из проекта получается нечто работающее, бизнес начинает конкретизировать свои желания, у них появляются идеи о новом функционале или просто новых бантиках, которые им не приходили раньше в голову. Иногда они видят, что то, что они хотели, на самом деле не так удобно и не так красиво, как им там мнилось, что на самом деле можно и так, и эдак. Вот тут при устном общении начинаются проблемы. Частенько совершенно не понятно, какое из принятых ранее решений сейчас в силе. Более того, со стороны бизнеса начинаются разногласия, и чаще всего они возникают уже после того, как разработчик реализовал какое-то решение. А все потому, что беседа велась по аське с одним человеком, когда остальные были на обеде. И потом, далеко не каждый мессенджер обладает нормальной функцией поиска по истории.
2. Результаты обсуждений в почте - вообще неприемлемо. Там постоянно образуется по нескольку версии одного документа, и далеко не всегда понятно, кто кому на какой вопрос отвечал.
3. Просто документы с контролем версий - это формализм. Ведение вордовых и экселевых документов - это не "гибко". Это не двусторонее общение, это не коммуникации - это постулирование и констатация требований. В теории, если правильно вести документы, то все будет, казалось бы, отлично. Но тут сыграет свою роль человеческий фактор. Кто будет фиксировать в документе все изменения и следить за актуальностью? Специально выделенный человек? Он не будет этого делать. Чтобы делать это, надо хорошо разбираться во всем проекте. А тем людям, которые хорошо разбираются во всем проекте, обычно не до этого. Чаще всего таким человеком назначают ("назначают" - опять какое-то слово из не-agile лексикона) либо самого младшего со стороны бизнеса, который и в самой предметной области проекта не очень-то шарит, либо бизнес-аналитика, который будет заниматься только ведением документов, то есть станет единственным бюрократом в проекте. За это его перестанут любить и начнут игнорировать. И вообще, формальность отношений в команде противоречит религии "agile" :).
4. Вероятно, wiki очень неплохо зарекомендовала бы себя, но для нашего бизнеса wiki в новинку. Кроме того, в вики достаточно удобно фиксировать уже сложившиеся требования, но неудобно вести обсуждения. Вики хорошо подходит для энциклопедии, для хелпера - но не для коммуникаций.
В блогах же каждый участник команды может постить впечатления и размышления, там будут получаться обсуждения, там бывает нормальный поиск. В конце концов, там есть rss. Думаю, комбинация нескольких блогов, вики, ну и, понятно, багтрекера, вполне сойдет за хороший рабочий инструмент.
